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

"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Thu, 13 September 2012 13:51 UTC

Return-Path: <rgandhi@cisco.com>
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 9657221F8564 for <ccamp@ietfa.amsl.com>; Thu, 13 Sep 2012 06:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.447
X-Spam-Level:
X-Spam-Status: No, score=-7.447 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8]
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 Oj+h1jqhFJom for <ccamp@ietfa.amsl.com>; Thu, 13 Sep 2012 06:51:25 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 799C921F85A2 for <ccamp@ietf.org>; Thu, 13 Sep 2012 06:51:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21000; q=dns/txt; s=iport; t=1347544284; x=1348753884; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8ziilnZD/GpUJhPxcPVB8Eh6Ou7KXtCLWy2tWurO4LA=; b=A+qHIbmqeWwYfsgZWzfpHqu8RlOh3wWWJxCGRt8wHy6N1RO64d5H6NZC UkvCKrtlys1hoaHJMI6bu3AuH66YfJegIYAp/QMmch0iZNGCyeODM7QEJ mstpJTNHVVAsFNLGU3EKkUnX2h6T04VEUmeFhTfEWWeRcsYplktDtRjjZ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAJbjUVCtJV2a/2dsb2JhbABFhge0eW+BB4IgAQEBBBIBFA0zEgwEAgEGAg4DBAEBAQQGHQUCAjAUCQgCBA4FCBMHh2ubb40TCJMZgR2Jc4UhNmADpBWBaYJmghc
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="121221374"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 13 Sep 2012 13:51:21 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8DDpLtX002589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Sep 2012 13:51:21 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Thu, 13 Sep 2012 08:51:21 -0500
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: Lou Berger <lberger@labn.net>
Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: Ac2Hf3Os+VLHAQPjT0mEShgHpTx4wgDXVW4AAAiZetABSEkbsAA8itKAAAUdObAAASWMgAAIiywQAAku1IAACmMi4P//vSoAgABP6SCAAG7CgIAAUrMg//+1zACAAFG0wA==
Date: Thu, 13 Sep 2012 13:51:20 +0000
Message-ID: <B7D2A316AA32B6469D9670B6A81B7C24098CD5@xmb-aln-x07.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> <5051E07A.40505@labn.net>
In-Reply-To: <5051E07A.40505@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.213.162]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19180.005
x-tm-as-result: No--68.475100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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:51:27 -0000

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:lberger@labn.net] 
Sent: Thursday, September 13, 2012 9:33 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

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