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

Lou Berger <lberger@labn.net> Thu, 13 September 2012 13:32 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCF321F8533 for <ccamp@ietfa.amsl.com>; Thu, 13 Sep 2012 06:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.819
X-Spam-Level:
X-Spam-Status: No, score=-98.819 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g9OTxH0VAWp for <ccamp@ietfa.amsl.com>; Thu, 13 Sep 2012 06:32:45 -0700 (PDT)
Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 9FE5121F8498 for <ccamp@ietf.org>; Thu, 13 Sep 2012 06:32:45 -0700 (PDT)
Received: (qmail 27209 invoked by uid 0); 13 Sep 2012 13:32:45 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 13 Sep 2012 13:32:45 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=TzuqWDOkOWo1jKmTLmZz+QI9NuTyYj7RprP/jRew9dY=; b=0tXcdWAvlzZgBWprjCJQtgwfXUcEOuQZQUAx9Ulv/fIBjdeUW3pKAekKYFLHQw8ItJEk0WHka838jN0stBtLGxdO4XOnbKsUzD1YvlDfcfRCABiHFtkxmLIw/bB87Hva;
Received: from box313.bluehost.com ([69.89.31.113]:58791 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1TC9XA-00020q-P6; Thu, 13 Sep 2012 07:32:45 -0600
Message-ID: <5051E07A.40505@labn.net>
Date: Thu, 13 Sep 2012 09:32:42 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
References: <B7D2A316AA32B6469D9670B6A81B7C2409895E@xmb-aln-x07.cisco.com> <OFF0A17BBD.DF3CC958-ON48257A78.00085C95-48257A78.000926A8@zte.com.cn> <B7D2A316AA32B6469D9670B6A81B7C24098A1E@xmb-aln-x07.cisco.com> <5051D959.2010809@labn.net> <B7D2A316AA32B6469D9670B6A81B7C24098C79@xmb-aln-x07.cisco.com>
In-Reply-To: <B7D2A316AA32B6469D9670B6A81B7C24098C79@xmb-aln-x07.cisco.com>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2012 13:32:47 -0000

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:lberger@labn.net] 
> Sent: Thursday, September 13, 2012 9:02 AM
> To: Rakesh Gandhi (rgandhi)
> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
> 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:*zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
>> *Sent:* Wednesday, September 12, 2012 9:40 PM
>> *To:* Rakesh Gandhi (rgandhi)
>> *Cc:* ccamp@ietf.org; Lou Berger
>> *Subject:* RE: Question on LSP control in 
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>>  
>>
>>
>> Hi Rekesh, 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)" <rgandhi@cisco.com 
>> <mailto:rgandhi@cisco.com>>*
>>
>> 2012-09-13 08:53
>>
>> 	
>>
>> 收件人
>>
>> 	
>>
>> "zhang.fei3@zte.com.cn <mailto:zhang.fei3@zte.com.cn>"
>> <zhang.fei3@zte.com.cn <mailto:zhang.fei3@zte.com.cn>>
>>
>> 抄送
>>
>> 	
>>
>> "ccamp@ietf.org <mailto:ccamp@ietf.org>" <ccamp@ietf.org 
>> <mailto:ccamp@ietf.org>>, Lou Berger <lberger@labn.net 
>> <mailto:lberger@labn.net>>
>>
>> 主题
>>
>> 	
>>
>> RE: Question on LSP control in
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>>  
>>
>> 	
>>
>>
>>
>>
>> Hi Fei,
>>  
>> Please see inline..<RG>..
>>  
>> *From:*zhang.fei3@zte.com.cn <mailto:zhang.fei3@zte.com.cn> 
>> [mailto:zhang.fei3@zte.com.cn] <mailto:[mailto:zhang.fei3@zte.com.cn]> 
>> *
>> Sent:* Wednesday, September 12, 2012 8:42 PM*
>> To:* Rakesh Gandhi (rgandhi)*
>> Cc:* ccamp@ietf.org <mailto:ccamp@ietf.org>; 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)" <**rgandhi@cisco.com*
>> <mailto:rgandhi@cisco.com>*>*
>>
>> 2012-09-13 01:23
>>
>> 	
>>
>>  
>>
>> 收件人
>>
>> 	
>>
>> Lou Berger <lberger@labn.net <mailto:lberger@labn.net>>
>>
>> 抄送
>>
>> 	
>>
>> "zhang.fei3@zte.com.cn <mailto:zhang.fei3@zte.com.cn>"
>> <zhang.fei3@zte.com.cn <mailto:zhang.fei3@zte.com.cn>>, 
>> "ccamp@ietf.org <mailto:ccamp@ietf.org>" <ccamp@ietf.org 
>> <mailto:ccamp@ietf.org>>
>>
>> 主题
>>
>> 	
>>
>> 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:lberger@labn.net] 
>> <mailto:[mailto:lberger@labn.net]>
>> Sent: Wednesday, September 12, 2012 12:14 PM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: zhang.fei3@zte.com.cn <mailto:zhang.fei3@zte.com.cn>; 
>> ccamp@ietf.org <mailto:ccamp@ietf.org>
>> 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:lberger@labn.net] 
>>> <mailto:[mailto:lberger@labn.net]>
>>> Sent: Wednesday, September 12, 2012 9:15 AM
>>> To: Rakesh Gandhi (rgandhi)
>>> Cc: zhang.fei3@zte.com.cn <mailto:zhang.fei3@zte.com.cn>; 
>>> ccamp@ietf.org
>> <mailto:ccamp@ietf.org>
>>> 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: zhang.fei3@zte.com.cn <mailto:zhang.fei3@zte.com.cn>; 
>>>> ccamp@ietf.org
>> <mailto:ccamp@ietf.org>
>>>> 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:lberger@labn.net] 
>>>> <mailto:[mailto:lberger@labn.net]>
>>>> Sent: Tuesday, September 04, 2012 11:35 AM
>>>> To: Rakesh Gandhi (rgandhi)
>>>> Cc: zhang.fei3@zte.com.cn <mailto:zhang.fei3@zte.com.cn>; 
>>>> ccamp@ietf.org
>> <mailto:ccamp@ietf.org>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>