RE: Question on RFC4873

["Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>]

Hi Lou,

The text is a bit confusing...

Section 4.2.4.2 has a reference to Section 4.2.3 and in this section the Path and Resv message processing is described.

Section 4.2.3 talks about message co-ordination at the branch nodes. The described method works fine when in response to a Path message with D+R bits set a Resv with D bit set is generated at the egress location. I believe in order for PathErr message with the Path_State_Removed option set it is probably necessary to have some message coordination at the merge nodes.  as well. The Path messages with D+R bits set from all branches need to be received at the merge node before the message can be forwarded downstream. This is required in order to ensure that the primary and secondary (recovery) LSPs can be deleted in a graceful manner.

Thanks,
Snigdho


-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
Behalf Of Lou Berger
Sent: Friday, September 21, 2007 12:09 PM
To: Bardalai, Snigdho
Cc: lberger@labn.net; IBryskin@advaoptical.com;
dimitri.papadimitriou@alcatel-lucent.be; adrian@olddog.co.uk; Ccamp
(E-mail)
Subject: Re: Question on RFC4873


Snigdho,

see responses in-line.

At 12:07 PM 9/21/2007, Bardalai, Snigdho wrote:

>Hi,
>
>RFC3473 has specified an option that allows tearing down an LSP 
>using the PathErr message with the Path_State_Removed option. If 
>this option is used in combination with the ADMINSTATUS object with 
>the D and R bits set in the Path message LSPs can be torn down in a 
>graceful manner.
>
> From reading RFC4873 it seems like this option is no longer 
> supported for the segment recovery LSPs. Section 4.2.4.2 in RFC4873 
> requires that when a Path message with D and R bits set is 
> received, a Resv with the D bit set MUST be sent.

I don't see this.  Section 4.2.4.2 only relates to path senders (aka 
"the ingress node").  The draft doesn't limit/modify use of the 
PathErr message with the Path_State_Removed option. (Handling of such 
messages at the recovery LSP ingress is covered in 4.2.1.)

Lou

>What exactly is this addressing? From what I can see there is no 
>strong technical reason to not support PathErr with 
>Path_State_Removed for graceful teardown. Or is there one?
>
>Regards,
>Snigdho