Subject: RE: RSVP HOP on PathErr

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

Further thought...

This issue might (possibly) resolve if Link Id is carried on a PathErr.

So far we only have a description for Path and Resv.  Has anyone given any
thought to other messages, and where in those messages it will be carried?

Adrian

>-----Original Message-----
>From: Adrian Farrel 
>Sent: Tuesday, September 19, 2000 9:08 PM
>To: Lou Berger
>Cc: [email-masked]
>Subject: RE: RSVP HOP on PathErr
>
>
>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:41:05 -0400

Adrian,

This seems reasonable to me.  (Particularly if it kills this thread 
;-)  Looking at the messages, the <sender descriptor> looks like the right 
place for the LINK_ID object.

I'll talk to Kireeti...

Lou