Re: [CCAMP] Discussion on how to carry the Global_ID

Lou Berger <lberger@labn.net> Wed, 08 February 2012 16:15 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 813C721F879B for <ccamp@ietfa.amsl.com>; Wed, 8 Feb 2012 08:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.556
X-Spam-Level:
X-Spam-Status: No, score=-98.556 tagged_above=-999 required=5 tests=[AWL=1.605, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ro81ulgcGfo for <ccamp@ietfa.amsl.com>; Wed, 8 Feb 2012 08:15:43 -0800 (PST)
Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id BE6A321F8796 for <ccamp@ietf.org>; Wed, 8 Feb 2012 08:15:43 -0800 (PST)
Received: (qmail 1769 invoked by uid 0); 8 Feb 2012 16:15:42 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 8 Feb 2012 16:15:42 -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=UkOvKr12prxwLn+M9HJOAYRPk32GCkQ/ORtuC+cVPAo=; b=CVA+VnSFLHMdAOUdMAItMQ9aIT3TKeY2SB8pHJdWqWr0rtKxdR9EtuVsvv/46n1yX1LwdWl+uvPOwWvcYkq+ubewVMe+LYHoXI92WMn64vEzK9ULY+Zx4iNLGWlzQh8g;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1RvABJ-00006y-IN; Wed, 08 Feb 2012 09:15:41 -0700
Message-ID: <4F329FA9.2070707@labn.net>
Date: Wed, 08 Feb 2012 11:15:37 -0500
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: Mach Chen <mach.chen@huawei.com>
References: <2EEA459CD95CCB4988BFAFC0F2287B5C25917498@SZXEML520-MBS.china.huawei.com> <OF8234A400.3AFAFF34-ON4825799D.002C2EA9-4825799D.002EA8F1@zte.com.cn> <CABP12JzdeFE=05KXe9PB3TYLzRcTqkW=0LOF1jsFX4Ai=2WuwQ@mail.gmail.com> <4F31285C.6040107@labn.net> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE21A56B843@SZXEML511-MBS.china.huawei.com>
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE21A56B843@SZXEML511-MBS.china.huawei.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
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: "mpls@ietf.org" <mpls@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Discussion on how to carry the Global_ID
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: Wed, 08 Feb 2012 16:15:45 -0000

Mach,
	Sounds like a good discussion to have with the authors of RFC6370...

Lou


On 2/7/2012 8:17 PM, Mach Chen wrote:
> Hi Lou,
> 
> I am always assume that the Z9-tunnel-num equals to A1-tunnel-num
> (for co-routed bidirectional LSP). The motivation (from the text of
> RFC6370 and the past discussion on MPLS-TP identifier) of two
> tunnel-nums is for simplifying associated bidirectional signaling,
> for co-routed bidirectional LSP, two tunnel-nums are unnecessary. If
> I am wrong, please correct me.(cc MPLS WG)
> 
> IMHO, the simplest way is to explicitly clarify that for co-routed
> bidirectional LSP, A1-tunnel-num=Z9-tunnel-num, maybe a clarification
> errata is needed for RFC6370.
> 
> Best regards, Mach
> 
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of
>> Lou Berger
>> Sent: Tuesday, February 07, 2012 9:34 PM
>> To: Francesco Fondelli
>> Cc: ccamp@ietf.org
>> Subject: Re: [CCAMP] Discussion on how to carry the Global_ID
>>
>> Francesco,
>> 	From my perspective, the (minimum) requirements are being driven by
>> rfc6370. Take a look at sections 5.2 and 5.3, and see if you still think
>> more mechanisms are being defined than is necessary.
>>
>> Lou
>>
>> On 2/7/2012 3:56 AM, Francesco Fondelli wrote:
>>>
>>> Am I the only one here that feels "uncomfortable" with this approach and
>>> this additional Z9-Tunnel_Num index in GMPLS flying from egress to
>>> ingress (for no reason?!?)? It might be naive or even stupid but I'd
>>> like to understand why we have to add another index... please shed some
>>> light on me.
>>>
>>> [I'm talking about co-routed bidi, I don't care about associated]
>>>
>>> thank you
>>> ciao
>>> FF
>>>
>>> 2012/2/7 <zhang.fei3@zte.com.cn <mailto:zhang.fei3@zte.com.cn>>
>>>
>>>
>>>     Vero
>>>
>>>     Why is tunnel number not known by node A? The tunnel number should
>>>     has been carried in Session and Sender Template/Filter Spec object
>>>     and exchanged by node A and node Z during the LSP set-up. Correct me
>>>     if I am wrong.
>>>
>>>     According to the description of RFC6370, section 5.1
>>>        At each end point, a tunnel is uniquely identified by the end point's
>>>       Node_ID and a locally assigned tunnel number.  Specifically, a
>>>       "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique
>>>       within the context of the Node_ID.  The motivation for each end
>> point
>>>       having its own tunnel number is to allow a compact form for the
>>>       MEP_ID.
>>>
>>>     Which means that for co-routed bidrectional LSP, there are two
>>>     tunnel numbers, one is locally assigned at node A and the other is
>>>     locally assigned at node Z.
>>>     If the signaling message is initialized at node A, the tunnel number
>>>     carried in Session/Sender Template objects is locally assigned at
>>>     node A. Of course, a new
>>>     C-type,like type=8, can be defined in the class of SESSION to carry
>>>     back the tunnel number assigned at node Z; but according to the
>>>     discussion with George, I do not think it is a good idea which is
>>>     not backward compatible.
>>>
>>>     Regards
>>>
>>>     Fei
>>>
>>>
>>>     *Vero Zheng <vero.zheng@huawei.com
>> <mailto:vero.zheng@huawei.com>>*
>>>
>>>     2012-02-07 15:33
>>>
>>>
>>>     收件人
>>>     	"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: [CCAMP] Discussion on how to carry the Global_ID
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>     Fei,
>>>
>>>     Please see in-line.
>>>
>>>     BR,
>>>     Vero
>>>
>>>     Fei,
>>>
>>>     you wrote:
>>>
>>>     First,
>>>     “2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01
>>>
>>>     The Global_ID Object and the ICC_Operator_ID Object are defined in
>>>     this draft,  which describes the procedure of corouted bidirectional
>>>     LSP (associated bidirectional LSP is not covered in the current
>>>     version) and requires that the same format( Global_ID or
>>>     ICC_Operator_ID)is used along the LSP.
>>>
>>>     Which is not true. The Object we defined could be carried in both
>>>     Path/Resv message, and is not restricted either to co-routed
>>>     bi-directional LSP or associated bi-directional LSP.
>>>
>>>     <fei>
>>>     Although either co-routed or associated bidirectional LSP is not
>>>     mentioned in this draft , according to  the descripition in section
>>>     2.3, " If the node agrees, it MUST use the same format of Operator
>>>     ID.  The same C-Type of OIO MUST be carried in the Resv message",
>>>     which means that  the procedure is for corouted bidrectional LSP.
>>>     The above is just my understanding and provided for discussion, and
>>>     if it is wrong or inaccurate, please let me know.
>>>     </fei>
>>>     The procedure described above aims to guarantee the sender and the
>>>     receiver using the same C-Type of the object, i.e. both end using
>>>     Global_ID or both using ICC_Operator_ID.
>>>
>>>     Second,
>>>     3.
>>>
>> http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-0
>> 1
>>>
>>>
>>>     The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which
>>>     will appear in the Path/Resv message of corouted bidrectional LSP
>>>     and only appear in the Path message of associated bidirectional LSP.
>>>     Furthermore, this draft defined a Connection TLV used to carry the
>>>     local tunnel number assigned at Z9 nodes in the scenario of corouted
>>>     bidirectional LSP.
>>>
>>>     Why “tunnel number” is carried in the Connection TLV? I don't see
>>>     its necessary for both co-route/ associated bi-directional LSP.
>>>     Could you explain?
>>>
>>>     <fei>
>>>     As I said, it is useful for corouted (not associated) bidirectional
>>>     LSP,  consider that there is one LSP (LSP1, initiated at node A)
>>>     between node A/Z.
>>>     If the CC-V pakcet is  sent from  node Z, the MEP_ID of node Z will
>>>     be inserted in the OAM packets, which is organized by
>>>     node_ID::tunnel_num::LSP_num
>>>     (section 5.2.1 or 7.2.2 of RFC6370), and if this MEP_ID is not
>>>     pre-stored at node A, it can not judge whether this MEP_ID is valid.
>>>     See the description in section 5.1.1.2
>>>     (*Mis-Connectivity Defect*) of RFC6371.
>>>                       LSP1
>>>     A-------------------------------Z
>>>
>>>
>>>     </fei>
>>>     Why is tunnel number not known by node A? The tunnel number should
>>>     has been carried in Session and Sender Template/Filter Spec object
>>>     and exchanged by node A and node Z during the LSP set-up. Correct me
>>>     if I am wrong.
>>>
>>>     BR,
>>>     Vero
>>>
>>>     Thanks.
>>>
>>>     Vero
>>>
>>>      *
>>>     From:* ccamp-bounces@ietf.org <mailto:ccamp-bounces@ietf.org>
>>>     [mailto:ccamp-bounces@ietf.org <mailto:ccamp-bounces@ietf.org>]
>> *On
>>>     Behalf Of *zhang.fei3@zte.com.cn <mailto:zhang.fei3@zte.com.cn>*
>>>     Sent:* Sunday, January 29, 2012 5:50 PM*
>>>     To:* ccamp@ietf.org <mailto:ccamp@ietf.org>*
>>>     Subject:* [CCAMP] Discussion on how to carry the Global_ID
>>>
>>>
>>>     Hi CCAMPers
>>>
>>>     As discussed in the last IETF meeting and mailinglist, the Global_ID
>>>     should be carried in the signaling messages. One reason is that the
>>>     judgement of a mis-connectivity defect needs the A1/Z9 nodes to
>>>     pre-store each other's MEP_ID, whose format is:
>>>     Gobal_ID+Node_ID+Tunnel_num+LSP_num.
>>>
>>>     Fortunately, there are several drafts related to this topic now,
>>>
>>>     1.  http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01.
>>>
>>>     The Globa_ID is incorporated into the ASSOCIATION object in the
>>>     current version, which guarantees that the association is global
>>>     unique. Since the ASSOCIATION object is used across different LSPs,
>>>     just my2cents, the defined format is deficient to handle more
>>>     scenarios. For example:
>>>
>>>       (1) Considering a corouted bidirectional LSP, which is not
>>>     protected by other LSPs through control plane and/or does not share
>>>     the same resoures with other LSPs. In these cases, the ASSOCIATION
>>>     object will not be carried in the sigaling messages.
>>>
>>>       (2) Considering an associated bidirectional LSP, although the
>>>     ASSOCIATION object is carried in the sigaling messages, the
>>>     global_ID incorporated in the ASSOCIATION object only
>>>     indicates the global prefix of the A1 or Z9 nodes. If this LSP is
>>>     across different domains, I think the current format is also
>>>     deficient (A1 does not know the gobal ID of Z9 node or Z9 nodes does
>>>     not know the global ID of A1 ).
>>>
>>>     2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01
>>>
>>>     The Global_ID Object and the ICC_Operator_ID Object are defined in
>>>     this draft,  which describes the procedure of corouted bidirectional
>>>     LSP (associated bidirectional LSP is not covered in the current
>>>     version) and requires that the same format( Global_ID or
>>>     ICC_Operator_ID)is used along the LSP.
>>>
>>>     3.
>>>
>> http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-0
>> 1
>>>
>>>
>>>     The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which
>>>     will appear in the Path/Resv message of corouted bidrectional LSP
>>>     and only appear in the Path message of associated bidirectional LSP.
>>>     Furthermore, this draft defined a Connection TLV used to carry the
>>>     local tunnel number assigned at Z9 nodes in the scenario of corouted
>>>     bidirectional LSP.
>>>
>>>
>>>     The above materials only provide the rough background.
>>>
>>>
>>>     Hope to hear the opinions from the WG that how to carry the
>>>     Global_ID, then move the work forward.
>>>
>>>
>>>     Best regards
>>>
>>>     ;)
>>>
>>>     Fei
>>>
>>>     _______________________________________________
>>>     CCAMP mailing list
>>>     CCAMP@ietf.org <mailto:CCAMP@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp