Subject: RE: RSVP HOP on PathErr

From: Adrian Farrel <[email-masked]>
Date: Tue, 19 Sep 2000 20:14:31 +0100

Everything said by everyone (?) so far is absolutely true.

It is always possible to get around the issue by mapping from Session Object
to Path State and thence to stored LIH value.

I guess I could ask, "Why is RSVP HOP on Resv?"  After all, you can still
get this information from the Path State.  The answer is that it is simpler
to apply the Resv to the correct interface by working with the RSVP HOP.
LIH provides a useful shortcut to the real or virtual interface that the
Resv should apply to.

2205 says...

      Some topologies of RSVP routers and non-RSVP routers can cause
      Resv messages to [snip] arrive at the wrong interface of the 
      correct node. [snip] To handle the wrong interface case, a 
      "Logical Interface Handle" (LIH) is used.  The previous hop
      information included in a Path message includes not only the
      IP address of the previous node but also an LIH defining the
      logical outgoing interface; both values are stored in the path
      state.  A Resv message arriving at the addressed node carries both
      the IP address and the LIH of the correct outgoing interface, i.e,
      the interface that should receive the requested reservation,
      regardless of which interface it arrives on.

      The LIH may also be useful when RSVP reservations are made over a
      complex link layer, to map between IP layer and link layer flow
      entities.

With out-of-band signaling and optical links (perhaps a cluster of virtual
links hiding behind one physical link) it is useful to be able to work out
the correct interface at which to apply the Resv.  LIH gives you this.

In GMPLS, you may (will?) have done some reservation on the forward path
(i.e. when the Path passed through).  This reservation is associated with an
interface (surprise!).  When you receive a PathErr then, depending on
implementation, you may need/want to release some of that reservation.
Using the LIH to get to the interface quickly will be helpful.

Alternatively, in the distributed RSVP situation that John (Drake)
describes, the Path State will be maintained on one of many processors.  The
Resv/PathErr is received at an interface "owned" by some other processor.
How to get the message to its Path State?

Answers
- extract Session Object, use undisclosed method to map to
  correct processor, pass the message there for processing
- extract LIH to identify the correct processor.

I prefer the second option.

(BTW before we go down the road of suggesting that the correct approach is
to ensure that the Resv/PathErr is addressed to an IP address on the correct
processor, note that this would require the RSVP HOP on the Path to identify
that address.  This would mean lying (shock!) since the actual egress
interface at the LSR would not have the address quoted in the RSVP HOP.
When this was discussed with Lou, I believe he had some good reasons why it
wouldn't work.)

So, it remains the case that it is possible to get the information that I
want by returning to the Path State, but this is graceless.  I admit that it
is not the role of the protocol to sort out my or John's implementation
issues, but can anyone suggest a concrete reason why not to add RSVP HOP to
PathErr?

(Please note that I am NOT proposing any change to RFC 2205.)

Regards,
Adrian
--
Adrian Farrel  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

>-----Original Message-----
>From: David Charlap [mailto:[email-masked]]
>Sent: Tuesday, September 19, 2000 7:11 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: RSVP HOP on PathErr
>
>
>Adrian Farrel wrote:
>> 
>> Here's a bit of controversy for you!
>> 
>> I just polled the RSVP list to see if anyone recalled why 
>PathErr does
>> not carry RSVP HOP.  Bob Braden helpfully replied that it 
>was left out
>> because it was not needed (reasonable enough!).
>> 
>> Can I suggest that it now has its uses in MPLS, especially 
>GMPLS where
>> a reservation may already have been made on the forward path (i.e.
>> when the Path message was processed) and it is necessary to get back
>> to the same interface (identified by the LIH) when the PathErr is
>> received.
>
>It's still not necessary.
>
>Your router has existing path state.  It knows the interface that it
>sent the Path message out on - and therefore knows the 
>next-hop address.
>
>If/when multicast support is added to RSVP-TE, then this may become a
>real problem.  In that situation, there may be multiple next-hops, and
>you'd have to figure out which one the PathErr came from.  But until
>then, there is no real need.
>
>-- David
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 19 Sep 2000 15:41:36 -0400

Adrian,
         In MPLS, where we don't have non-RSVP nodes and RSVP messages are 
always processed hop-by-hop, the outgoing interface of an upstream router 
will always receive the PathErr sent by a downstream node.  Furthermore the 
IP destination address of the PathErr message will match the address used 
in the PHOP/RSVP_HOP of the Path message.

In most distributed approaches I've heard about this interface would the 
one that processes the PathErr and it will have information on related 
incoming interfaces, so there is no issue.

You seem to be implying that the outgoing interface won't have such 
information.  First let me say this seems very non-intuitive and probably 
is causing lots of confusion.  If this is the case you are concerned about, 
then it seems you are asking everyone to change their existing 
implementations to accommodate one specific implementation's issue.

Certainly such an issue could be addressed if we were dealing with a virgin 
protocol, but we're not.  So my feeling is that you should deal with your 
special case, rather than making the rest of us optimize for you.

Does anyone else see this as important???

Lou