Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Tue, 04 September 2012 16:26 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 4A85D11E809A for <ccamp@ietfa.amsl.com>; Tue, 4 Sep 2012 09:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.396
X-Spam-Level:
X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.001, 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 6YsEjDYTFjsp for <ccamp@ietfa.amsl.com>; Tue, 4 Sep 2012 09:26:50 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1FE21F84DA for <ccamp@ietf.org>; Tue, 4 Sep 2012 09:26:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=7932; q=dns/txt; s=iport; t=1346776010; x=1347985610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=H3Gpw+MdffMB9kO+/VrvHvMTHEGzsyjfaAjK/qmWeiI=; b=bIDyn7iZYdVHMIoy89+bFaGvBpc/EzfBJYsLEYJWQNDwqNaIzVlZZOvl UI00k9jaZpOzINsZNjFzTuSxfZcOoUyWLzaronkuF7IymijCnASYfydJq oIX/NQwHCZze3rSnJsmB2pfeI7VqFAPpY4Y+8VlxePbq+HgI8Pw4cZcCy Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAL4qRlCtJV2Z/2dsb2JhbAA7CoYFtDB2gQeCIAEBAQQSASEzEgwEAgEGAg4DBAEBAQQGGQQFAgIwFAkIAgQBDQUIGodrmmONEwiSXoEdiXAQBIYINmADpAyBZ4JjgVg
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="118127028"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 04 Sep 2012 16:26:49 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q84GQnuE009076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 16:26:49 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 11:26:48 -0500
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: Lou Berger <lberger@labn.net>, "zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.cn>
Thread-Topic: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: AQHNhMO1KWryoN3/QKaPbjEu2q9iw5dvgLYAgAroR+A=
Date: Tue, 04 Sep 2012 16:26:47 +0000
Message-ID: <B7D2A316AA32B6469D9670B6A81B7C24078559@xmb-aln-x07.cisco.com>
References: <OF60768B2E.0B179745-ON48257A68.000CB1F8-48257A68.000CC8D5@zte.com.cn> <503CBDC2.9040308@labn.net>
In-Reply-To: <503CBDC2.9040308@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.245.61]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19160.005
x-tm-as-result: No--52.159100-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] Review Request For Changes 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: Tue, 04 Sep 2012 16:26:51 -0000

Thanks Lou.

Your proposal below sounds good.

Potential text for the remained two sections in the draft can be as follows. Please feel free to revise.

3.2.6 Signaling of Associated Bidirectional LSP For Different LSP Roles
There can also be a pair of recovery and/or reroute LSPs as per procedures define in [RFC4872], [RFC4873] and [RFC4090]. Together with those procedures, a node uses Extended ASSOCIATION object or ASSOCIATION object defined in this document to form an associated bidirectional LSP pair for each LSP role.

3.2.7. Signaling of Auto-tunnel Mesh-group LSPs
   A node may build LSPs automatically to remote peers in a mesh using
   the mesh-group membership defined in [RFC4972]. A node MUST be provisioned with identical association ID
   for the given mesh-group members peers to build a mesh of associated bidirectional LSPs. The extended
   association ID can be used to form unique Extended ASSOCIAITON object in each LSP to different remote peers.


Thanks,
Rakesh


-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net] 
Sent: Tuesday, August 28, 2012 8:47 AM
To: zhang.fei3@zte.com.cn
Cc: ccamp@ietf.org; Rakesh Gandhi (rgandhi)
Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Fei,

I don't think the text addresses the issue of selection of association object contents in the case of double sided provisioning.  How about:
- in the case of double sided provisioning *only*
  1. Association Source is set to an address selected by the node that
     originates the association. (which may be a management entity.)
  2. Association ID is a value assigned but the node that originates
     the association.
  3. Global Association Source, when used, is set to the Global_ID of
     the node that originates the association.
  4. Extended Association ID, when used, is selected by the node that
     originates the association.
  -  If either (3) or (4) are used, an Extended ASSOCIATION object
     [assoc-ext] is used.  Otherwise a ASSOCIATION object [rfc4872]
     is used

- while we're at it, in the case of single sided provisioning *only* (note only #1 differs)
  1. Association Source is set to an address assigned to the node that
     originates the LSP.
  2. Association ID is a value assigned but the node that originates
     the association.
  3. Global Association Source, when used, is set to the Global_ID of
     the node that originates the association.
  4. Extended Association ID, when used, is selected by the node that
     originates the association.
  -  If either (3) or (4) are used, an Extended ASSOCIATION object
     [assoc-ext] is used.  Otherwise a ASSOCIATION object [rfc4872]
     is used

I think the above addresses my point as it can be used to ensure unique LSP association in all cases.  BTW it also aligns very nicely with the existing definition of the association objects.

To address what I suspect is your concern, 3.2.8 can then become something like (feel free to revise):

  3.2.8  MPLS-TP Associated Bidirectional LSP Identifiers

  [RFC6370] defines the LSP associated identifiers based on the
  signaling parameters of each unidirectional LSP. The combination
  of each unidirectional LSP's parameters is used to identify the
  Associated Bidirectional LSP.  Using the mechanisms defined in
  this document, any node that is along the path of both
  unidirectional LSPs can identify which pair of unidirectional LSPs
  support an Associated Bidirectional LSP as well as the signaling
  parameters required by [RFC6370].  Note that the LSP end-points
  will always be the path of both unidirectional LSPs.

Lou

On 8/27/2012 10:20 PM, zhang.fei3@zte.com.cn wrote:
> 
> Thank you lou
> 
> How about changing the descriptions in paragraph 3.2.8
> 
>    In some scenarios, a node that is the association source MAY need to
>   learn about the Global_ID [RFC6370] of the peer node, which can be
>   done by inserting the ASSOCIATION object with Association Type "LSP
>   identifiers" in the outgoing Path message and being carried back in
>   the Resv message, as defined in [I-D, draft-zhang-ccamp-mpls-tp-
>   rsvpte-ext-tunnel-num].
> 
> into
> 
>    In some scenarios, a node that is the association source MAY need to
>   learn about the Global_ID [RFC6370] of the peer node. Although the
>    scope of the draft [I-D,
> draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num]
>    is limited to the co-routed bidirectional LSP, the defined 
> procedures can
>    be reused here also. The ASSOCIATION object with Association Type "LSP
>   Identifiers" is inserted in the outgoing Path message at the association
>    source and carried back in the corresponding Resv message. All the 
> fields
>    of the ASSOCIATION object except the Association Type in the Path 
> message
>    can be ignored by the receiver and the Global_ID of the peer node 
> is pushed
>    into the field of the Global Association Source in the Resv message.
> 
> Best regards
> 
> Fei
> 
> 
> *Lou Berger <lberger@labn.net>*
> 
> 2012-08-28 02:30
> 
> 	
> 收件人
> 	zhang.fei3@zte.com.cn
> 抄送
> 	"ccamp@ietf.org" <ccamp@ietf.org>, "Rakesh Gandhi (rgandhi)"
> <rgandhi@cisco.com>
> 主题
> 	Re: [CCAMP] Review Request For Changes in 
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> 
> 	
> 
> 
> 
> 
> 
> Fei,
>                 The problem only exists in the double sided 
> provisioing case, so no need to complicate the single sided 
> provisioning case.
> 
> Lou
> 
> 
> On 8/26/2012 9:03 PM, zhang.fei3@zte.com.cn wrote:
>> The administrative
>> approach can integrate both models, will be a good idea.
> 
>