The MPLS-OPS Archive

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

> > >
> > > This is certainly possible, but not the way TE was intended to be
> > > used, nor how at least one implementation out there behaves.  Think of
> > > a TE LSP as a unidirectional traffic trunk between two nodes in the
> > > provider's network.  Customer A and Customer B traffic between the
> > > same two nodes takes the same trunk.  Seperation is done by DiffServ
> > > and EXP bits.
> >
> >
> > is this cisco specific?
> > does cisco support "TED" and RSVP-TE EROs based on TED parameters?
> >
>
> We support RSVP-TE ERO.  We support a TE DB based on OSPF and/or ISIS
> extensions.

what about constraints other than "explicit-route"?

so we can have data from TED passing OSPF-TE extensions based on opaque
LSAs?


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