Subject: RE: RSVP HOP on PathErr

From: Adrian Farrel <[email-masked]>
Date: Tue, 19 Sep 2000 21:08:23 +0100

Lou,

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

Yes, I think I worked that one out a while ago.

What about MPLS implementations where you DO have non-RSVP (even non-MPLS)
nodes?  Think about out-of-band signaling.  Here, you signal through an IP
cloud but your data uses entirely distinct interfaces.  This isn't RSVP;
this is MPLS.

It is absolutely the case that the received PathErr will carry the address
from the PHOP of the Path.  And what address will that be?  Will it be the
address of the data interface - no.  Will it be the address of the interface
through which the PathErr is received - maybe.  If it matches an IP
interface not a data interface how to we discover which data interface we
are dealing with? - do we have to find the Path State and work from there?

This is not the forum to compare and contrast implementations or to try to
run anyone down.  I refuse to be drawn by the following paragraphs.

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

No one is asking anyone to change their implementations in any substantial
way.  Are you really saying that it is more than 10 lines of code to include
RSVP HOP in PathErr?

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

Are you saying that we must protect implementations of early versions of the
draft that are already in the field?  Surely not: the draft evolves until it
is stable and then goes to RFC.

>Does anyone else see this as important???

Clearly I do. John Drake spoke in favor too, I recall.

I would certainly like to hear from the guys in the optical space who are
planning o-o-b signaling.  Perhaps they have a view.

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

---

From: Lou Berger <[email-masked]>
Date: Tue, 19 Sep 2000 16:35:03 -0400

Adrian,
         I'm not trying to attack you or your implementation.  You asked 
the question "can anyone suggest a concrete reason why not to add RSVP HOP to
PathErr?"  My response is that this is the wrong question, because you are 
suggesting changing something specified in RFC2205.  This is a 
philosophical position, not one of effort required.

Because you are suggesting modifying something that is a standard (not a 
draft) I believe the question should be "can anyone suggest a concrete 
reason why to add RSVP HOP to PathErr?"

 From my perspective, the only reason I've heard stated is related to a 
particular boundary case with a particular implementation.   To me, this 
doesn't seem like a strong enough reason to change the base, rfc2205 
specified, message format.

Lou