The MPLS-OPS Archive

[Eric Osborne <eosborne@cisco.com>]

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.  

> 
> 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).

> 
> 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.

> 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.

> 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.




eric

> 
> 
> 
> 
> 
> 
> >
> > > so we can have data from TED passing OSPF-TE extensions based on opaque
> > > LSAs?
> > >
> >
> > yes.
> >
> >
> >
> >
> > eric
> >
> > >
> > > >
> > > > > > > >2. What's the behavior of RSVP, when it's configured to
> constrain &
> > > > > > > >reserved a 20 MB? Will it maintain 20MB LSP permanently
> regardless
> > > the
> > > > > > > >traffic usage (no tear down)?
> > > > > > >
> > > > > >
> > > > > > Yes.  But in at least our implementation, the reservation is
> > > > > > control-plane only.  The idea is to build a reservation for
> something
> > > > > > like 95th percentile of your traffic between two points.
> > > > >
> > > > >
> > > > > Can you please elaborate?
> > > >
> > > > Rather than constantly changing a reservation in increments of (say)
> > > > 1k all the time based on actual traffic flow, build a TE LSP that
> > > > reserves some sort of mean or mean-like amount of bandwidth between
> > > > two points.  This is not a vendor-specific thing, it is a network
> > > > design thing.
> > >
> > > can you please elaborate "all the time"?
> > >
> > > 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, rate-limiting per VPN at the PE is still needed)
> > >
> > >
> > >
> >
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> >

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