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

Mach Chen <mach.chen@huawei.com> Wed, 08 February 2012 01:17 UTC

Return-Path: <mach.chen@huawei.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 D5F2921F84EC; Tue, 7 Feb 2012 17:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.509
X-Spam-Level:
X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 A45RJfV8wDRu; Tue, 7 Feb 2012 17:17:39 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2639B21F84F6; Tue, 7 Feb 2012 17:17:36 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ100D8KVKQPD@szxga03-in.huawei.com>; Wed, 08 Feb 2012 09:17:14 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ1000N0VJ950@szxga03-in.huawei.com>; Wed, 08 Feb 2012 09:17:14 +0800 (CST)
Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX67176; Wed, 08 Feb 2012 09:17:14 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 08 Feb 2012 09:16:34 +0800
Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.206]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Wed, 08 Feb 2012 09:17:45 +0800
Date: Wed, 08 Feb 2012 01:17:03 +0000
From: Mach Chen <mach.chen@huawei.com>
In-reply-to: <4F31285C.6040107@labn.net>
X-Originating-IP: [10.108.4.51]
To: Lou Berger <lberger@labn.net>, Francesco Fondelli <francesco.fondelli@gmail.com>
Message-id: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE21A56B843@SZXEML511-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: en-US, zh-CN
Thread-topic: [CCAMP] Discussion on how to carry the Global_ID
Thread-index: AQHM3mtqrImy7nMdPk6BWVdOo7CN0ZYqcwYAgABMRgCABdMwAIAAD9MAgAAHloCAAE2MAIABRMig
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
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>
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 01:17:41 -0000

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