Subject: RE: RSVP HOP on PathErr

From: Bob Braden <[email-masked]>
Date: Sun, 1 Oct 2000 21:05:48 -0700 (PDT)

*> 
  *> Bob,
  *> 
  *> As I mentioned, we're dealing with a distributed implementation and we're
  *> trying to minimize the amount of replicated state information.  The PathErr
  *> as well as all other messages that flow towards the origin have to be
  *> transferred from the egress card to the correct ingress card, and having a
  *> separate mechanism for PathErr is a nuisance.
  *> 
  *> Thanks,
  *> 
  *> John
  *>

I am not fundamentally hostile to adding HOP to PathErr if there is a
good reason, but I interpret your comment above as an implementation
problem in a particular organization of the router hardware.  Did I
misinterpret?  Such considerations aside, I see NO separate mechanism;
the PathErr is routed upstream just as Resv messages are routed
upstream.

Bob Braden

  *> -----Original Message-----
  *> From: Bob Braden [mailto:[email-masked]]
  *> Sent: Tuesday, September 19, 2000 8:44 AM
  *> To: [email-masked]; [email-masked]; John Drake
  *> Cc: [email-masked]; [email-masked]; [email-masked];
  *> [email-masked]
  *> Subject: RE: RSVP HOP on PathErr
  *> 
  *> 
  *> 
  *>   *> From [email-masked] Tue Sep 19 08:13:33 2000
  *>   *> From: John Drake <[email-masked]>
  *>   *> To: "'Lou Berger'" <[email-masked]>, Adrian Farrel
  *> <[email-masked]>
  *>   *> Cc: [email-masked], [email-masked], [email-masked],
  *> [email-masked]
  *>   *> Subject: RE: RSVP HOP on PathErr
  *>   *> Date: Tue, 19 Sep 2000 08:13:22 -0700
  *>   *> MIME-Version: 1.0
  *>   *> X-Mailer: Internet Mail Service (5.5.2650.21)
  *>   *> X-Lines: 61
  *>   *> 
  *>   *> Lou,
  *>   *> 
  *>   *> I think the point is that since PathErr doesn't have HOP, it doesn't
  *> have
  *>   *> the LIH information.  This means that a node has to have another
  *> mechanism,
  *>   *> like Session ID, to get PathErr to the correct ingress interface, and
  *> this
  *>   *> is extra work and complexity, paticularly in a distributed
  *> implementation.
  *>   *> 
  *>   *> Thanks,
  *>   *> 
  *>   *> John
  *> 
  *> Why doesn't the path state tell you the correct incoming interface?
  *> You should have path state at all nodes upstream of the failure.
  *> 
  *> Bob Braden
  *> 
  *>   *> 
  *>   *> -----Original Message-----
  *>   *> From: Lou Berger [mailto:[email-masked]]
  *>   *> Sent: Tuesday, September 19, 2000 3:34 AM
  *>   *> To: Adrian Farrel
  *>   *> Cc: [email-masked]; [email-masked]; [email-masked];
  *>   *> [email-masked]
  *>   *> Subject: Re: RSVP HOP on PathErr
  *>   *> 
  *>   *> 
  *>   *> 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
  *>   *> 
  *>   *> At 04:45 AM 9/19/00, Adrian Farrel wrote:
  *>   *> >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
  *>   *> 
  *>