Subject: RSVP HOP on PathErr

From: Adrian Farrel <[email-masked]>
Date: Tue, 19 Sep 2000 09:45:06 +0100

Hi,

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.

Would either of you, for this reason or for symmetry, be prepared to put
RSVP HOP on PathErr in your drafts (rsvp-lsp-tunnel or
generalized-signaling)?

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

---

From: Lou Berger <[email-masked]>
Date: Tue, 19 Sep 2000 06:33:30 -0400

Adrian,

I don't see the need for this change, particularly since there are no 
non-RSVP hops with RSVP-TE.

In an abstract sense having HOP in PathErr is no big deal, but the call was 
made not to include it when the protocol was specified in RFC2205.  I don't 
think we should make changes in the base protocol just because of aesthetics.

What case do see where you can't "get back to the same interface" on 
receipt of a PathErr?

Lou

---

From: David Charlap <[email-masked]>
Date: Tue, 19 Sep 2000 14:10:55 -0400

Adrian Farrel wrote:
> 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