Sean/Shankar,
This is exactly where I am coming from, the multiple
access interface will have no idea what the remote
end can accept. I am surprised this is not clearly
mentioned at some places, I have been trying to
confirm this by surfing the web pages, but got
nothing.
Glad to get this cleared up
I certainly understand this has nothing to do with any
vendor's implementation.
Thanks a lot.
JUN
--- Sean Crocker <crockers@mail.trinicom.com> wrote:
> Jun,
>
> >I am just trying to think aloud here:
> >
> >If there is an LSP passing through the router, it
> >comes into interface A, goes out of interface B,
> >the RSVP reservation is only on interface B, is
> this
> >right? If so, how could we guarantee interface A
> will
> >have enough bandwidth for the tunnel, since its
> >bandwidth could be less than the outbound interface
> B.
>
> Normally that would not happen because the upstream
> node
> that's connected to interface A should fail the
> reservation
> (or actually the preceeding PATH) since it *should*
> have an
> accurate idea of the links's remaining reservable
> bandwidth.
>
> However, that holds true mainly for P2P links, not
> multiple
> nodes on a shared media. Even worse, consider the
> following:
>
>
Ingress(GigE)-Switch-(FastE)NodeA(GigE)--(GigE)Egress
>
> Here NodeA has only one upstream neighbor, which
> could swamp
> NodeA's FastEthernet interface. I don't think any
> CSPF
> implementations will check the "back-link" to
> prevent this
> (although I could be wrong). I suppose this is one
> situation
> that an offline path calculation server could
> address.
>
> This is more of an issue with the RSVP/RSVP-TE and
> not cisco's
> implementation per se. You should read the RFCs for
> a bit and
> perhaps post to mpls-ops@mplsrc.com if you still
> have concerns.
>
> Sean
>
> >
> >Thanks
> >JUN
> >
> >
> >--- Shankar Vemulapalli <svemulap@cisco.com> wrote:
> >> There is no need to reserve on inbound ...
> >>
> >> The path message goes out asking for reservation
> >> followed by resv message coming back either
> >> confirming or not.
> >> Once we receive the confirmation, we guarantee
> the
> >> reservation on the outgoing interface...
> >>
> >> So, the ingress traffic could be IP and doesn't
> >> have any reservation associated with it ... It
> >> now can get label switched on the outgoing
> interface
> >> because we have an LSP which is set up with some
> >> bandwidth guarantees...
> >>
> >> So, why do we need to make reservation on inbound
> >> interface ??
> >>
> >> Am I missing something ??
> >>
> >> Thanks,
> >>
> >> /Shankar
> >>
> >> At 2:13pm 05/01/02 -0700, JUN wrote:
> >> > Shankar,
> >> >
> >> > I understand that it is for simplex traffic,
> but
> >> it
> >> > takes two interfaces to handle a reservation,
> an
> >> > inbound and an outbound, why it is only
> necessary
> >> to
> >> > make reservation at outbound?
> >> >
> >> > Thanks
> >> > JUN
> >> >
> >> > --- Shankar Vemulapalli <svemulap@cisco.com>
> >> wrote:
> >> > > Well, as per the RFC2205 -
> >> > >
> >> > > " RSVP requests resources for simplex flows,
> >> i.e.,
> >> > > it requests
> >> > > resources in only one direction.
> >> > > "
> >> > >
> >> > > You may want to look into this RFC for more
> >> > > information
> >> > > as to how RSVP works...
> >> > >
> >> > > Also, look into RFC 3209 - (if you need
> further
> >> > > info.)
> >> > >
> >> > > Thanks,
> >> > >
> >> > >
> >> > > /Shankar
> >> > >
> >> > > At 1:06pm 05/01/02 -0700, JUN wrote:
> >> > > > I noticed that when an LSP passing through
> a
> >> > > router,
> >> > > > RSVP only reserves bandwidth of the
> outbound
> >> > > > interface, why it doesn't make reservation
> at
> >> > > inbound?
> >> > > >
> >> > > > Thanks
> >> > > > JUN
> >>
> >
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Health - your guide to health and wellness
> >http://health.yahoo.com
> >
> >
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:11:55 EDT