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

Lou Berger <lberger@labn.net> Tue, 28 August 2012 12:47 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 6E5C721F853D for <ccamp@ietfa.amsl.com>; Tue, 28 Aug 2012 05:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.173
X-Spam-Level:
X-Spam-Status: No, score=-98.173 tagged_above=-999 required=5 tests=[AWL=-0.462, 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 y1EAiNtvncxr for <ccamp@ietfa.amsl.com>; Tue, 28 Aug 2012 05:46:59 -0700 (PDT)
Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id A7DE121F8530 for <ccamp@ietf.org>; Tue, 28 Aug 2012 05:46:59 -0700 (PDT)
Received: (qmail 17993 invoked by uid 0); 28 Aug 2012 12:46:58 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 28 Aug 2012 12:46:58 -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=/L70w/2f+zxH8WZVewYOqb9bJWsvwCXKk/Vb/Nl1nds=; b=dskAjekfP4nfCR/qK5iFn6JmfR+nwDG58THnsNiamULkRaDDXRXICeKCsfgcD7ggVHQdhsU5oNLYHAGmnO8MBdA9CWYTpKSJ+kivk0DPEL0wtD39lv6fqfsqDbwcVHMU;
Received: from box313.bluehost.com ([69.89.31.113]:40032 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1T6LC6-0003ux-Dm; Tue, 28 Aug 2012 06:46:58 -0600
Message-ID: <503CBDC2.9040308@labn.net>
Date: Tue, 28 Aug 2012 08:46:58 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: zhang.fei3@zte.com.cn
References: <OF60768B2E.0B179745-ON48257A68.000CB1F8-48257A68.000CC8D5@zte.com.cn>
In-Reply-To: <OF60768B2E.0B179745-ON48257A68.000CB1F8-48257A68.000CC8D5@zte.com.cn>
X-Enigmail-Version: 1.0.1
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] 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, 28 Aug 2012 12:47:00 -0000

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