Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Mon, 4 Mar 2013 14:30:33 +0000

Hi WG,

Issue:
"When an initiating ingress node is provisioned with "Single Sided  Associated Bidirectional LSPs" and wishes to control both forward and  reverse LSPs by adding REVERSE_LSP object, the initiating ingress node SHOULD  know the signaling (path) errors on the reverse LSP. "

Solution proposal:
An egress node receiving ASSOCIATION object with association type "Single Sided  Associated Bidirectional LSPs" and REVERSE_LSP object can use following method to inform the path errors on the reverse LSP to the ingress node.

An egress node relays the received ERROR_SPEC object as is in the path error message to the ingress node. In addition, the egress node inserts the received ASSOCIATION object from the ingress node in the path error message to indicate to the ingress node that this path error is for the reverse LSP.

Advantages of this approach:
As both ingress and egress nodes already support the ASSOCIATION object, this method does not require support of new RSVP objects (e.g. NOTIFY message discussed below). ASSOCIATION object can also help further identify the affected LSP. This method also does not require new message support (e.g. NOTIFY message) at transit nodes.

Please advise your comments.

Thanks,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, September 13, 2012 3:32 PM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

My suggestion would be to leave this language out for now and include it once it's fully formed/edited and discussed.

Lou

On 9/13/2012 3:20 PM, Rakesh Gandhi (rgandhi) wrote:
> Hi Lou, WG,
> 
> We like to post the revised draft and might be an idea to include following text. Can you please review and advise? 
> 
> "When an initiating ingress node is provisioned with "Single Sided  Associated Bidirectional LSPs" and wishes to control both forward and  reverse LSPs by adding REVERSE_LSP object, the initiating ingress node SHOULD  know the signaling (path) errors on the reverse LSP.  An egress node receiving Association object with association type "Single Sided  Associated Bidirectional LSPs" and REVERSE_LSP object SHOULD use the NOTIFY message and procedures defined in RFC[3473] for relaying  signaling error on the reverse LSP to the initiating ingress node."
> 
> Thanks,
> Rakesh
> 
> 
> -----Original Message-----
> From: Rakesh Gandhi (rgandhi)
> Sent: Thursday, September 13, 2012 9:51 AM
> To: 'Lou Berger'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Question on LSP control in 
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> Hi Lou,
> 
> The NOTIFY request and reply procedures are defined in RFC3473 and can be used by any node who supports this RFC and this draft does not add/remove/modify any behavior/requirement in that regard. 
> 
> I didn't mean to include the NOTIFY request object in the REVERSE_LSP objects either.
> 
> Are we ok to add following text? 
> 
>  "When an initiating ingress node is provisioned with "Single Sided  Associated Bidirectional LSPs" and wishes to control both forward and  reverse  LSPs by adding "REVERSE_LSP" object, the ingress node SHOULD  know the signaling (path) errors on the reverse LSP.  
>  An egress node MAY use NOTIFY message and procedures defined in RFC[3473] for relaying  signaling error on the reverse LSP to the ingress node."
> 
> 
> Thanks,
> Rakesh
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Thursday, September 13, 2012 9:33 AM
> To: Rakesh Gandhi (rgandhi)
> Cc: [email-masked]; [email-masked]
> Subject: Re: Question on LSP control in 
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> If one wanted to be cute, an ingress could include a NOTIFY_REQUEST containing the ingress' address in the REVERSE_LSP object as well as the Resv messages of incoming associated bidirectional LSPs.  Of course, this means that the ingress would be notified of path errors for an LSP for which it doesn't have path state...
> 
> Do you really want to go down the path of document all possible uses/combination of objects carried in REVERSE_LSP objects?
> 
> Lou
> 
> On 9/13/2012 9:15 AM, Rakesh Gandhi (rgandhi) wrote:
>> Thanks Lou for your reply.
>>
>> Good to know that NOTIFY messages can be generated without NOTIFY request messages. Thanks for this info. So I agree that egress node SHOULD relay the signaling errors based on association type of "Single Sided Associated Bidirectional LSPs" and presence of "REVERSE_LSP" object.
>>
>> Having said that, if an ingress node supports RFC3473 and makes request by sending NOTIFY request message to a transit node, and transit node also supports RFC3473 and the NOTIFY reply, the reverse LSP signaling notification from this transit node can work as well independent of egress relaying the messages. Do you agree? 
>>
>> Thanks,
>> Rakesh
>>
>>
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:[email-masked]]
>> Sent: Thursday, September 13, 2012 9:02 AM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: Question on LSP control in 
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>> Rakesh,
>> 	This seems really complicated.  Why allow for the optional notification from the egress?  There is precedent for use of notify messages without notify requests (see RFC4974).
>>
>> Also, as it stands Associated Bidirectional really only requires support by the end nodes. (I think of it as almost an application overlay on top of normal LSP signaling.  I'd even consider using the RFC4974 call approach if it wasn't for requirement 11 in RFC6373.)  I think placing processing requirements on transit nodes, such as sending reverse_lsp notifications adds unnecessary complexity and should be avoided unless absolutely necessary.
>>
>> Lou (as participant)
>>
>> On 9/12/2012 9:57 PM, Rakesh Gandhi (rgandhi) wrote:
>>> Hi Fei,
>>>
>>>  
>>>
>>> I see what you are saying. Rewording the text to reflect this (not 
>>> sure about “SHOULD” word usage):
>>>
>>>  
>>>
>>> When an initiating ingress node is provisioned with "Single Sided 
>>> Associated Bidirectional LSPs" and wishes to control both forward 
>>> and reverse LSPs by adding "REVERSE_LSP" object, the ingress node 
>>> SHOULD know the signaling (path) errors on the reverse LSP. Transit 
>>> and egress nodes SHOULD be requested to notify the signaling error 
>>> on the reverse LSP by using the NOTIFY message and procedures defined in RFC[3473].
>>>
>>>  
>>>
>>>  
>>>
>>> Thanks,
>>>
>>> Rakesh
>>>
>>>  
>>>
>>>  
>>>
>>> *From:[email-masked] [mailto:[email-masked]]
>>> *Sent:* Wednesday, September 12, 2012 9:40 PM
>>> *To:* Rakesh Gandhi (rgandhi)
>>> *Cc:* [email-masked]; Lou Berger
>>> *Subject:* RE: Question on LSP control in 
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>>  
>>>
>>>
>>> Hi Rakesh, Lou
>>>
>>>  />          Speaking as WG participant, I haven't thought about this
>>> too much so may be off, but method 3 seems to be most consistent 
>>> with the usage of the REVERSE_LSP Object in the path message.  
>>> Perhaps consider using the REVERSE_LSP Object in the upstream/Resv 
>>> direction to allow the egress/tail to provide the ingress/head with 
>>> arbitrary information..../
>>>
>>> <fei>Well, I can see one of the advantages of this proposal is that 
>>> it allows the policy control in the egress/tail, where a decision 
>>> can be made that whether the signaling error should be passed to the 
>>> ingress/head. But it changes the rules defined in RFC3473....
>>>
>>>      The other proposal keeps alignment with RFC3473, and I prefer 
>>> it if the LSP control is totally in hand of the ingress/head (in 
>>> other words, there is no more information needs the egres/tail to 
>>> inform the ingress/head).
>>>
>>> *"Rakesh Gandhi (rgandhi)" <[email-masked]
>>> <mailto:[email-masked]>>*
>>>
>>> 2012-09-13 08:53
>>>
>>> 	
>>>
>>> 收件人
>>>
>>> 	
>>>
>>> "[email-masked] <mailto:[email-masked]>"
>>> <[email-masked] <mailto:[email-masked]>>
>>>
>>> 抄送
>>>
>>> 	
>>>
>>> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
>>> <mailto:[email-masked]>>, Lou Berger <[email-masked] 
>>> <mailto:[email-masked]>>
>>>
>>> 主题
>>>
>>> 	
>>>
>>> RE: Question on LSP control in
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>>  
>>>
>>> 	
>>>
>>>
>>>
>>>
>>> Hi Fei,
>>>  
>>> Please see inline..<RG>..
>>>  
>>> *From:[email-masked] <mailto:[email-masked]> 
>>> [mailto:[email-masked]] 
>>> <mailto:[mailto:[email-masked]]>
>>> *
>>> Sent:* Wednesday, September 12, 2012 8:42 PM*
>>> To:* Rakesh Gandhi (rgandhi)*
>>> Cc:* [email-masked] <mailto:[email-masked]>; Lou Berger*
>>> Subject:* RE: Question on LSP control in 
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>  
>>>
>>> Hi Rakesh
>>>
>>> In the absence of such notification request, egress node SHOULD 
>>> relay the received signaling error on the reverse LSP to the ingress 
>>> node using the NOTIFY message."
>>>
>>> <fei> "Note that a Notify message MUST NOT be generated unless an 
>>> appropriate Notify Request object has been received."
>>>
>>>       If my understanding is correct, your proposed relay mechanism 
>>> does not depend on the existing of the Notify Request object, which 
>>> may conflict with the
>>>       descripitons in RFC3473.
>>>
>>>       Do you want to change this or do I have some misunderstanding?  
>>>
>>> <RG> Yes your understanding is correct.  NOTIFY message in this case 
>>> is generated based on the presence of the “REVERSE_LSP” object and 
>>> association type “Single Sided Associated Bidirectional LSPs.  I 
>>> understand what you are saying though. FYI,  Lou had following 
>>> thoughts on this. Do you think this simplifies things ?
>>> />          Speaking as WG participant, I haven't thought about this too
>>> much so may be off, but method 3 seems to be most consistent with 
>>> the usage of the REVERSE_LSP Object in the path message.  Perhaps 
>>> consider using the REVERSE_LSP Object in the upstream/Resv direction 
>>> to allow the egress/tail to provide the ingress/head with arbitrary information....
>>> /
>>> Thanks,
>>> Rakesh
>>>  
>>>  
>>>
>>> Regards
>>>
>>> Fei
>>>
>>> *"Rakesh Gandhi (rgandhi)" <[email-masked]*
>>> <mailto:[email-masked]>*>*
>>>
>>> 2012-09-13 01:23
>>>
>>> 	
>>>
>>>  
>>>
>>> 收件人
>>>
>>> 	
>>>
>>> Lou Berger <[email-masked] <mailto:[email-masked]>>
>>>
>>> 抄送
>>>
>>> 	
>>>
>>> "[email-masked] <mailto:[email-masked]>"
>>> <[email-masked] <mailto:[email-masked]>>, 
>>> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
>>> <mailto:[email-masked]>>
>>>
>>> 主题
>>>
>>> 	
>>>
>>> RE: Question on LSP control in
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>>
>>>  
>>>
>>>  
>>>
>>> 	
>>>
>>>
>>>
>>>
>>>
>>> Hi Lou, Fei, WG,
>>>
>>> Thanks for your replies. May I propose following text to cover this 
>>> case? This allows the mid-point solution which has advantages but 
>>> given the additional complexity can be optional.
>>>
>>> Please advise.
>>>
>>> "When an initiating ingress node is provisioned with "Single Sided 
>>> Associated Bidirectional LSPs" and wishes to control both forward 
>>> and reverse  LSPs by adding "REVERSE_LSP" object, the ingress node 
>>> SHOULD know the signaling (path) errors on the reverse LSP.  A 
>>> transit node MAY be requested to notify the signaling error on the 
>>> reverse LSP by using the NOTIFY message and procedures defined in 
>>> RFC[3473]. In the absence of such notification request, egress node 
>>> SHOULD relay the received signaling error on the reverse LSP to the 
>>> ingress node using the NOTIFY message."
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:[email-masked]] 
>>> <mailto:[mailto:[email-masked]]>
>>> Sent: Wednesday, September 12, 2012 12:14 PM
>>> To: Rakesh Gandhi (rgandhi)
>>> Cc: [email-masked] <mailto:[email-masked]>; 
>>> [email-masked] <mailto:[email-masked]>
>>> Subject: Re: Question on LSP control in 
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>> Rakesh,
>>>
>>>
>>> On 9/12/2012 11:52 AM, Rakesh Gandhi (rgandhi) wrote:
>>>> Thanks Lou.
>>>>
>>>> Are we ok in general to use NOTIFY message [RFC3473] for this?
>>>
>>> I'm not speaking for the WG, as noted my comments were as a participant.
>>> IMO you'll need to fully document the proposal, perhaps discuss 
>>> alternatives considered, and then ask the WG for concurrence.
>>>
>>>>
>>>> One advantage with the mid-point sending notification for the 
>>>> reverse LSP is that signaling error propagation time
>>>> (mid->egress-node->ingress-node) is significantly reduced (to
>>>> mid->ingress-node) which may be preferred in some cases.
>>>
>>> >From my (personal) perspective, the added complexity isn't worth the effort.  Of course, a detailed proposal may show otherwise.
>>>
>>> Lou
>>>
>>>>
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:[email-masked]] 
>>>> <mailto:[mailto:[email-masked]]>
>>>> Sent: Wednesday, September 12, 2012 9:15 AM
>>>> To: Rakesh Gandhi (rgandhi)
>>>> Cc: [email-masked] <mailto:[email-masked]>; 
>>>> [email-masked]
>>> <mailto:[email-masked]>
>>>> Subject: Re: Question on LSP control in 
>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>
>>>> Rakesh,
>>>>                  Speaking as WG participant, I haven't thought 
>>>> about this too much so may be off, but method 3 seems to be most 
>>>> consistent with the usage of the REVERSE_LSP Object in the path message.
>>>> Perhaps consider using the REVERSE_LSP Object in the upstream/Resv 
>>>> direction to allow the egress/tail to provide the
>>> ingress/head with arbitrary information....
>>>>
>>>> Lou
>>>>
>>>> On 9/11/2012 9:22 AM, Rakesh Gandhi (rgandhi) wrote:
>>>>> Hi WG,
>>>>>
>>>>> Any thoughts on the following proposal?
>>>>>
>>>>> Thanks,
>>>>> Rakesh
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Rakesh Gandhi (rgandhi)
>>>>> Sent: Tuesday, September 04, 2012 1:36 PM
>>>>> To: 'Lou Berger'
>>>>> Cc: [email-masked] <mailto:[email-masked]>; 
>>>>> [email-masked]
>>> <mailto:[email-masked]>
>>>>> Subject: RE: Question on LSP control in 
>>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>>
>>>>>
>>>>> Thanks Lou for your reply.
>>>>>
>>>>> RFC 3473 defines procedures for NOTIFY request and reply. We could use this for reverse LSP signaling error notification to the initiating ingress node.
>>>>>
>>>>> <Notify message> ::= <Common Header> [<INTEGRITY>] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
>>>>> <ERROR_SPEC>   
>>>>> <notify session list ::= <upstream session> <downstream session>  
>>>>> >
>>>>>
>>>>> There are multiple ways we can use the NOTIFY message.
>>>>>
>>>>> Method 1 - Mid-point aware with Path message request:
>>>>> When an egress node receives a Path message with REVERSE_LSP object, the node will insert NOTIFY_REQ message in the reverse LSP path message with node ID of the initiating ingress node. A mid-point node will send  a copy of the signaling error to the initiating node using the NOTIFY message.
>>>>>
>>>>> IPv4 Notify Request Object
>>>>>    IPv4 Notify Node Address: 32 bits
>>>>>       The IP address of the node that should be notified when generating an error message.
>>>>>
>>>>> Method 2 - Mid-point aware with Resv message request:
>>>>> When an initiating ingress node receives a Path message for a reverse LSP, the node will insert NOTIFY_REQ message in the reverse LSP Resv message with its own node ID. A mid-point node will send a copy of the signaling error to the initiating node using the NOTIFY message.
>>>>>
>>>>> Method 3 - Tail-end relaying :
>>>>> When an egress node receives a Path message with REVERSE_LSP 
>>>>> object, the node will relay the received signaling error message 
>>>>> on the reverse LSP to the initializing ingress node. The egress 
>>>>> node copies the received "ERROR_SPEC" object into a NOTIFY 
>>>>> [RFC3473, section 4.3] message and signals it to the ingress node. 
>>>>> In this case,
>>> NOTIFY_REQ message is not required.
>>>>>
>>>>> Please advise your thoughts.
>>>>>
>>>>> Thanks,
>>>>> Rakesh
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Lou Berger [mailto:[email-masked]] 
>>>>> <mailto:[mailto:[email-masked]]>
>>>>> Sent: Tuesday, September 04, 2012 11:35 AM
>>>>> To: Rakesh Gandhi (rgandhi)
>>>>> Cc: [email-masked] <mailto:[email-masked]>; 
>>>>> [email-masked]
>>> <mailto:[email-masked]>
>>>>> Subject: Re: Question on LSP control in 
>>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>>
>>>>> As I read the current rev, no such notification mechanism is specified.
>>>>>  Looks like you get to propose one!
>>>>>
>>>>> Lou (as WG participant).
>>>>>
>>>>> On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote:
>>>>>> Hi Lou, Fei,
>>>>>>
>>>>>> When an (originating) ingress node is provisioned with "5 (TBD) 
>>>>>> Single Sided Associated Bidirectional LSPs  (A)" and wishes to 
>>>>>> control both forward and reverse  LSPs by adding "REVERSE_LSP"
>>>>>> object, I would think that the ingress node needs to know about 
>>>>>> the signaling (path) errors (such as soft preemption or admission
>>> failure) on the reverse LSP.  Is there any text somewhere in an 
>>> RFC/draft that describes how a mid-point node can send the signaling
>>> (path) error to the originating ingress node for the reverse LSP? Is 
>>> there an assumption to use RSVP_NOTIFY message? Sorry if I had 
>>> missed any previous discussion on this topic.
>>>>>>
>>>>>> Thanks,
>>>>>> Rakesh
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>