Subject: RE: RSVP HOP on PathErr

From: John Drake <[email-masked]>
Date: Tue, 19 Sep 2000 08:13:22 -0700

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

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

---

From: Bob Braden <[email-masked]>
Date: Tue, 19 Sep 2000 15:43:52 GMT

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

---

From: John Drake <[email-masked]>
Date: Tue, 19 Sep 2000 08:52:54 -0700

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

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

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

---

From: Bob Braden <[email-masked]>
Date: Tue, 19 Sep 2000 15:57:00 GMT

Folks,

I am too busy at the moment to do anything other than shoot from
the hip, but there seems to be a lot of confusion here.  The LIH
is the logical OUTGOING interface handle.  The path state should
tell you the incoming interface.  I don't understand your problem,
clearly, but what I see written about it makes little sense to me.

Bob Bradne

---

From: Lou Berger <[email-masked]>
Date: Tue, 19 Sep 2000 12:00:13 -0400

John,
         In the case you mention, the message will be received on the 
interface that sent the path, so no problem.

I'm trying to contrive a case where this is a real issue, but am having 
difficulty.  Can you describe the specific problem/issue?

Thanks,
Lou

---

From: Eric Gray <[email-masked]>
Date: Tue, 19 Sep 2000 11:05:09 -0700

John,

	For you to be able to avoid this nuisance, it
would be necessary for inclusion of RSVP HOP to be
mandatory.  Otherwise it might be omitted and you 
would then have to fall back on the nuisance.  If
we are going to add a requirement to include RSVP 
HOP to every PathErr message, isn't this likely to
be a nuisance (at least for some people) as well?

--
Eric Gray

> From: John Drake [mailto:[email-masked]]
> Sent: Tuesday, September 19, 2000 8:53 AM
> To: 'Bob Braden'; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: John Drake <[email-masked]>
Date: Tue, 19 Sep 2000 11:02:58 -0700

Eric,

I talked with Lou this morning and he made the same point.  The thought was
that this might become common usage over time in TE networks and that a
PathErr w/o a HOP could be deprecated.  

Thanks,

John

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Tuesday, September 19, 2000 11:05 AM
To: John Drake; 'Bob Braden'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: RSVP HOP on PathErr

John,

--
Eric Gray

---

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

Just to be clear:

At 02:02 PM 9/19/00, John Drake wrote:
>Eric,
>
>I talked with Lou this morning and he made the same point.

I agree with Eric.

My specific point was that it's too late to make changes to the basic 
protocol (rfc2205) solely based on aesthetics.

The rest of the text wasn't discussed.

Lou

>  The thought was