Subject: RSVP Hop on PathErr

From: Adrian Farrel <[email-masked]>
Date: Mon, 18 Sep 2000 20:35:08 +0100

Hi,

I've been polling around a bit privately but had no luck.

Can any of you with long memories recall why PathErr does not contain the
RSVP Hop object?  Is it as simple as the fact that sometimes (rarely?) the
node sending the PathErr is not the node identified in the RSVP Hop on the
Path?

All thoughts appreciated.

TIA
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: Mon, 18 Sep 2000 20:33:06 GMT

*> From [email-masked] Mon Sep 18 12:39:31 2000
  *> From: Adrian Farrel <[email-masked]>
  *> To: [email-masked]
  *> Subject: RSVP Hop on PathErr
  *> Date: Mon, 18 Sep 2000 20:35:08 +0100
  *> MIME-Version: 1.0
  *> X-Mailer: Internet Mail Service (5.5.2650.21)
  *> Sender: [email-masked]
  *> Precedence: bulk
  *> X-Lines: 19
  *> 
  *> Hi,
  *> 
  *> I've been polling around a bit privately but had no luck.
  *> 
  *> Can any of you with long memories recall why PathErr does not contain the
  *> RSVP Hop object?  Is it as simple as the fact that sometimes (rarely?) the
  *> node sending the PathErr is not the node identified in the RSVP Hop on the
  *> Path?
  *> 

Mainly, I believe, because a Hop object would serve no function in
a PathErr message.  It seemed simpler to leave it out than to put it
in and have to explain that it was not useful.  (Se, here I am
explaining anyway! ;-) )

The HOP object in a Resv message carries the LIH and next hop address
for merging reservations and putting them on the correct outgoing
interface.  PathErr messages are not merged and do not care about
outgoing interfaces.

Bob Braden

  *> All thoughts appreciated.
  *> 
  *> TIA
  *> 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: Adrian Farrel <[email-masked]>
Date: Tue, 19 Sep 2000 09:45:03 +0100

Thanks Ping,

Yes you're right, the information (i.e. LIH) could be carried in other
fields by extending them.  However, we already have an object for exactly
this purpose and something of a lack of symmetry by leaving it out of
PathErr.

wrt to ERO, I don't think this tells us the next hop at all.  It will tell
us the direction in which to route, but that's all.

Regards,
Adrian

>-----Original Message-----
>From: Ping Pan [mailto:[email-masked]]
>Sent: Monday, September 18, 2000 10:47 PM
>To: Adrian Farrel
>Cc: [email-masked]
>Subject: Re: RSVP Hop on PathErr
>
>
>Adrian,
>
>Why do you need RSVP_HOP in MPLS? The sender knows exactly where the
>error spot is from the EXPLICIT_ROUTE object, which is generated by the
>sender itself. Plus, you can always extend the ERROR_SPEC to 
>include any useful information such as LIH, right?
>
>- Ping
>
>Adrian Farrel wrote:
>> 
>> Bob,
>> 
>> Thanks for a speedy response.
>> 
>> I guess that leaves it up to the MPLS WG, who are generally
>> munching RSVP, anyway to add RSVP_HOP to PathErr if they
>> believe they have a use for it.
>> 
>> FYI, GMPLS raises the specter of reserving resources on the
>> forward path and so it may be important to be able to get
>> back to the correct interface (using LIH) if the Path setup
>> fails.
>> 
>> Regards,
>> Adrian
>