Re: [CCAMP] Discussion on how to carry the Global_ID
zhang.fei3@zte.com.cn Wed, 08 February 2012 00:40 UTC
Return-Path: <zhang.fei3@zte.com.cn>
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 C149711E8073 for <ccamp@ietfa.amsl.com>; Tue, 7 Feb 2012 16:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.683
X-Spam-Level:
X-Spam-Status: No, score=-96.683 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 ezzmEGwUd9Yq for <ccamp@ietfa.amsl.com>; Tue, 7 Feb 2012 16:40:14 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 48C4911E8072 for <ccamp@ietf.org>; Tue, 7 Feb 2012 16:40:13 -0800 (PST)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690473195744; Wed, 8 Feb 2012 08:13:35 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 5467.2563153982; Wed, 8 Feb 2012 08:40:02 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q180duti090561; Wed, 8 Feb 2012 08:39:57 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn)
In-Reply-To: <CABP12JwHHpttQnASq7VVmkorsgaBMF0sS8Ee8+pPHwKEiBVmpQ@mail.gmail.com>
To: Francesco Fondelli <francesco.fondelli@gmail.com>
MIME-Version: 1.0
X-KeepSent: 79DAAA88:075A6C20-4825799E:0002114F; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF79DAAA88.075A6C20-ON4825799E.0002114F-4825799E.0003A739@zte.com.cn>
From: zhang.fei3@zte.com.cn
Date: Wed, 08 Feb 2012 08:39:53 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-08 08:39:57, Serialize complete at 2012-02-08 08:39:57
Content-Type: multipart/alternative; boundary="=_alternative 0003A7344825799E_="
X-MAIL: mse02.zte.com.cn q180duti090561
Cc: "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 00:40:15 -0000
Francesco See in line with <fei></fei> Just my2cents Best Fei Francesco Fondelli <francesco.fondelli@gmail.com> 2012-02-07 21:14 收件人 zhang.fei3@zte.com.cn 抄送 Vero Zheng <vero.zheng@huawei.com>, "ccamp@ietf.org" <ccamp@ietf.org> 主题 Re: [CCAMP] Discussion on how to carry the Global_ID Hi, if this is the only use case I strongly suggest you to make anything related to Z9-Tunnel_Num OPTIONAL in signaling (dunno if this is the case in your I-D). Please. <fei> I just describe this usecase in the current draft, and the Z9-Tunnel_Num is OPTIONAL. If we consider the service access at Z9 node, the index will be shorter, but it is related to the concrete realization. Furthermore, I am not sure whether it will have influence on the IGP ShortCut, need to think about it. </fei> BTW, I'm wondering... if this is just about MEP ID what's the relation of your I-D and this one: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-07 <fei> Actually, I pointed out this on the last IETF meeting presentation material,please check the following link: http://tools.ietf.org/agenda/82/slides/ccamp-10.pdf </fei> Why not simply assume that A1-Tunnel_Num == Z9-Tunnel_Num ? (for co-routed bidi) and leave GMPLS in peace? <fei> In the practical implementation, we can do this. But the Tunnel space is independent from each other at every node, which means that the conflicting will happen. </fei> thanks ciao FF 2012/2/7 <zhang.fei3@zte.com.cn> Francesco Below is one usecase based on my understanding. A1----------------Z9 (co-routed) The MEP_ID of A1 is A1:Global_ID::Node_ID::Tunnel_Num::LSP_Num, similarly the MEP_ID of Z9 is Z9:Global_ID::Node_ID::Tunnel_Num::LSP_Num. Consider that CC-V packets are sent from Z9 to A1, MEP_ID of Z9 is inserted in the CC-V packets. The Mis-Connectivity Defect (RFC6371) is declared based on the comparison of expected MEP_ID and received MEP_ID, so A1 needs to pre-store the MEP_ID of Z9. For static LSP, the exchanges of LSP identifers can be realized by the GAP (G-ACh Advertisement Protocol) protocol defined in the draft http://tools.ietf.org/html/draft-ietf-mpls-gach-adv-00. As to dynamically established LSP, which can be carried in the signaling message. I am not sure whether the interpretation is reasonable to you. Best regards Fei Francesco Fondelli <francesco.fondelli@gmail.com> 2012-02-07 16:56 收件人 zhang.fei3@zte.com.cn 抄送 Vero Zheng <vero.zheng@huawei.com>, "ccamp@ietf.org" <ccamp@ietf.org> 主题 Re: [CCAMP] Discussion on how to carry the Global_ID 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> 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> 2012-02-07 15:33 收件人 "zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.cn> 抄送 "ccamp@ietf.org" <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-01 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] On Behalf Of zhang.fei3@zte.com.cn Sent: Sunday, January 29, 2012 5:50 PM To: 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-01 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 https://www.ietf.org/mailman/listinfo/ccamp
- Re: [CCAMP] Discussion on how to carry the Global… Lou Berger
- [CCAMP] Discussion on how to carry the Global_ID zhang.fei3
- Re: [CCAMP] Discussion on how to carry the Global… Lou Berger
- Re: [CCAMP] Discussion on how to carry the Global… zhang.fei3
- Re: [CCAMP] Discussion on how to carry the Global… Vero Zheng
- Re: [CCAMP] Discussion on how to carry the Global… zhang.fei3
- Re: [CCAMP] Discussion on how to carry the Global… zhang.fei3
- Re: [CCAMP] Discussion on how to carry the Global… Vero Zheng
- Re: [CCAMP] Discussion on how to carry the Global… zhang.fei3
- Re: [CCAMP] Discussion on how to carry the Global… Francesco Fondelli
- Re: [CCAMP] Discussion on how to carry the Global… zhang.fei3
- Re: [CCAMP] Discussion on how to carry the Global… Francesco Fondelli
- Re: [CCAMP] Discussion on how to carry the Global… Lou Berger
- Re: [CCAMP] Discussion on how to carry the Global… Francesco Fondelli
- Re: [CCAMP] Discussion on how to carry the Global… zhang.fei3
- Re: [CCAMP] Discussion on how to carry the Global… Mach Chen
- Re: [CCAMP] Discussion on how to carry the Global… Lou Berger