The MPLS WG Archive

["Arashmid Akhavain" <arashmid@hotmail.com>]

Thanks for your reply David. I have included some quick comments
to further clarify my view on the matter.

Regards,
Arashmid


>From: David Charlap <David.Charlap@marconi.com>
>To: Arashmid Akhavain <arashmid@hotmail.com>
>Subject: Re: path for RSVP-TE RESV message
>Date: Mon, 25 Feb 2002 11:53:56 -0500
>
>Arashmid Akhavain wrote:
> >
> > RFC 2205 in section 2.9 States that:
> >
> > If the destination address does not match any local interface and
> > the message is not a Path or PathTear, the message must be forwarded
> > without further processing by this node.
>
>Yes.
>
> > Isn't this a contradiction to what RFC3209 says?
>
>Where is the contradiction.  I just looked again and I don't see a
>requirement that Resv messages must be dropped under this situation.
>

I did not mean to imply that Resv messages must be dropped
under this condition at all. On the contrary, I am trying to
emphasize that in either RSVP or RSVP-TE, messages other than Path
and PathTear must be forwarded without processing under the above condition.

That is, even in RSVP-TE, under the unlikely scenario
that N3 receives the Resv message that is destined for interface A
on N1 (perhaps due to manual configuration of N2's routing table), N3
MUST forward this Resv Message to N1 (normal IP forwarding) so that
N1 could establish the LSP.

Now, I totally agree that in RSVP-TE networks this can only
happen iff the routing table is manually configured to use a sub-optimal 
route.


Arashmid


> > Consider the diagram below where all nodes are RSVP-TE capable nodes
> > and they are all directly connected.
> >
> >         ----      PATH        ----
> >        |    |    ------>     |    |
> >        | N1 |----------------| N2 |
> >        |    |A              B|    |
> >        |____|                |____|
> >          |F                    C|
> >          |                      |
> >          |                      |
> >          |         ----         |
> >          |       E|    |D       |
> >          |________| N3 |________|
> >                   |    |
> >                   |____|
> >
> > Based on 2205, N2 can build a RESV message, hands it to IP as
> > payload with DA = A. IP can either send it out on interface B (most
> > logical choice since it's N2's local interface to the same subnet as
> > A) or it can send it out on interface C depending on the routing
> > information in N2.
>
>Correct.
>
> > Are we saying that an RSVP-TE node must ignore its routing table and
> > it must always use the interface it received the PATH message from
> > to respond back with the RESV? Is this the case for other RSVP
> > messages as well?
>
>Yes.  There are other cases where RSVP-TE must ignore the routing table
>- like when processing a Path message with an ERO.  The packet has the
>session address as its destination, but the next-hop interface is chosen
>based on the first non-local subobject in the ERO message.
>
>In general, all messages flowing downstream should be addressed to the
>session address, and should have Router Alert set, so that they will be
>processed by the proper intermediate nodes.  The next-hops chosen for
>these messages should always follow the ERO (for non-Path messages, the
>ERO will be stored from the most-recently-received Path message, and
>should be available.)
>
>All messages flowing upstream should be addressed to the PHOP address.
>And they should be sent out the PHOP interface.  Router Alert should not
>be set.  Since the PHOP router is going to be directly attached
>(non-RSVP routers are forbidden), this will guarantee that the packet
>will be received on the correct interface as well.
>
> > If not, then if N2 sends the RESV out on interface C and N3
> > does not forward the packet to N1, the LSP is not going to
> > be established.
>
>N3 will forward the packet.  It's an ordinary IP datagram addressed to
>some other node.  Since the Router Alert option is not set, it should
>forward the packet without processing it in any way.
>
> > But if N3 forwards the packet to N1 without any further processing,
> > although N1 receives the RESV message through its interface F, it
> > can still identify the corresponding PSB (Note that PSB is
> > associated with link AB) and associate the arrived label with link
> > AB.
>
>N1 will receive the Resv message.  And it can identify the PSB.  The
>outgoing interface used by the Path message can be identified this way.
>
>But such a scenario would not happen in reality, because RSVP neighbors
>will always be directly connected under RSVP-TE.  The packets will
>always be delivered directly to the neighbor (even if the interface
>doesn't match), unless the routing table is deliberately configured to
>use a sub-optimal route.
>
>-- David






_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com