Subject: RE: path for RSVP-TE RESV message

From: "Feng, Mark" <[email-masked]>
Date: Mon, 25 Feb 2002 11:01:48 -0800

IMO, the Resv message should be sent out at the interface where Path is
received. This is true for RSVP-TE as indicated below; and it should be true
as well for classical RSVP. I don't see the value of querying the routing
table, since the path is known at this point.

The statement quoted below regarding the handling of message, IMO, does not
apply to unicast. Like David indicated below, all the messages traverse in
the reverse direction shouldn't have the router alert on. As a result, even
if the message arrives at a different router, RSVP module at that router
shouldn't even see it.

- Mark

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Monday, February 25, 2002 8:54 AM
> To: [email-masked]
> Subject: Re: path for RSVP-TE RESV message
> 
> 
> 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.
> 
> > 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
>

---

From: "Arashmid Akhavain" <[email-masked]>
Date: Mon, 25 Feb 2002 18:56:30

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

Regards,
Arashmid

>From: David Charlap <[email-masked]>
>To: Arashmid Akhavain <[email-masked]>
>Date: Mon, 25 Feb 2002 11:53:56 -0500
>
>Arashmid Akhavain wrote:
> >

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

>Yes.  There are other cases where RSVP-TE must ignore the routing table
>session address as its destination, but the next-hop interface is chosen
>session address, and should have Router Alert set, so that they will be
>these messages should always follow the ERO (for non-Path messages, the
>All messages flowing upstream should be addressed to the PHOP address.
>And they should be sent out the PHOP interface.  Router Alert should not
>outgoing interface used by the Path message can be identified this way.
>
>But such a scenario would not happen in reality, because RSVP neighbors

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