The MPLS-OPS Archive

["john smith" <johnsmith0302@hotmail.com>]

some more points...

----- Original Message -----
From: Eric Osborne <eosborne@cisco.com>
To: john smith <johnsmith0302@hotmail.com>
Cc: Eric Osborne <eosborne@cisco.com>; MPLS-ops Mailing List
<mpls-ops@mplsrc.com>
Sent: Monday, February 24, 2003 11:25 PM
Subject: Re: Fwd: [MPLS-OPS]: RSVP and LSP Questions


> On Mon, Feb 24, 2003 at 11:15:25PM +0530, john smith wrote:
> > Thanks for your replies Eric,
> >
> > Just some clarifications,
> >
> > > > > We support RSVP-TE ERO.  We support a TE DB based on OSPF and/or
ISIS
> > > > > extensions.
> > > >
> > > > what about constraints other than "explicit-route"?
> > > >
> > >
> > > we support the extensions in rfc3209, plus some local constraints.
> > > see your friendly neighborhood CCO docs (or this really good book I
> > > head about once..:) ) for more detail.
> >
> >
> > ........on the lines of draft katz-yeung......cum 3209
>
> draft-katz-yeung and draft-isis-traffic are packet formats for OSPF
> and ISIS; 3209 is mostly about RSVP.

agreed.

>
> >
> > so lets see now, you support "passing of information on the TE DB via
opaque
> > LSAs, at any given time you know how much of the "bandwidth" is
> > subscribed...but there is no way as of now to "set the upper limit" on
the
> > bandwidth...am i correct?
>
> a node controls how much bandwidth it advertises on a link.  the IGP
> drafts have space for not only max reservable, but also physical max
> (so you can oversubscribe intelligently).


yes, you can say "this is the max under RSVP, this is the used up and this
is left  behind"....thats in the drafts

>
> >
> > i did see the automatic-reservation mechanism on your site, quite
> > interesting...is that what you were referring to in the "mean like"
amount?
> >
>
> no...95th percentile or something like that, perhaps a weighted
> average.  Depends on the provider.


fine, taking a 95% on the bandwidth distribution...agreed.

>
> > about the other part:
> >
> > on the other bit.....
> >
> >  can you please elaborate "all the time"?
> >
>
> continuously...
>
> The point I was trying to make is that you shouldn't go re-sizing TE
> tunnels based on microbursts, but just to size the tunnel reasonably
> (95th percentile or whatever you like) and leave it at that, using
> diffserv mechanisms to sort out any congestion wherever it might
> happen.

hmmmm...... large ftp file downloads?

>
> > how do you ever ensure that the user "never bursts" beyond his capacity
?
> >
>
> you sometimes don't; that's why you build an LSP to 95th percentile.
>
> >  the reservations normally need to be done only at the time of LSP
setup.
> >  (i agree its not a hard limit nor am i asking for the RSVP instance to
talk
> >  to the policer, but i think rate-limiting per VPN at the PE is still
> > needed)
>
> It often is, it depends what you've sold.  If you sold a 1.5Mbit/sec
> SLA over a T1 access circuit, you don't need to rate-limit anything
> since it's inherently done by the T1 network.  But this is largely
> orthogonal to TE.

then lets do away with routers and stick to SDH multiplexers and use GMPLS
on them ;-) ?

unfortunately we still may have 2Mb last mile links (it could be lets say
113kbps subscribed over a wire which supports 2Mb is what i mean)

there maybe cases where the implementation says 1Mb till here and .5 Mb till
there...what about that? you still need to rate limit at the edge, dont you?

why not "cap" ...why let the last mile "wire" control that bit?

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml