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

Francesco Fondelli <francesco.fondelli@gmail.com> Tue, 07 February 2012 08:56 UTC

Return-Path: <francesco.fondelli@gmail.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 4979A21F869E for <ccamp@ietfa.amsl.com>; Tue, 7 Feb 2012 00:56:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.624
X-Spam-Level:
X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 8TWyAdE2waCH for <ccamp@ietfa.amsl.com>; Tue, 7 Feb 2012 00:56:47 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A281121F869C for <ccamp@ietf.org>; Tue, 7 Feb 2012 00:56:47 -0800 (PST)
Received: by yhkk25 with SMTP id k25so3267773yhk.31 for <ccamp@ietf.org>; Tue, 07 Feb 2012 00:56:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qauclBwyx3U8c0+eCCBc4sJCosBc0/FnqGwKN0Iw204=; b=ckc543iRhJXWMoP19MwV+iO7JhFW1SkcUzGeNuVZwnydYnkT40GrcmMpe0xV64/tCp KmLSzxFuRJvPOBw6eZlhSENq+hHJrhlWFwK6YBPIgFD6e3Qhhf86xV3EvuhkPKO19xT3 GVbSIeOQzEBOBmgsUupZNpFl47CTqdBt1RDJA=
MIME-Version: 1.0
Received: by 10.236.175.164 with SMTP id z24mr29735394yhl.84.1328605007149; Tue, 07 Feb 2012 00:56:47 -0800 (PST)
Received: by 10.236.155.103 with HTTP; Tue, 7 Feb 2012 00:56:47 -0800 (PST)
In-Reply-To: <OF8234A400.3AFAFF34-ON4825799D.002C2EA9-4825799D.002EA8F1@zte.com.cn>
References: <2EEA459CD95CCB4988BFAFC0F2287B5C25917498@SZXEML520-MBS.china.huawei.com> <OF8234A400.3AFAFF34-ON4825799D.002C2EA9-4825799D.002EA8F1@zte.com.cn>
Date: Tue, 07 Feb 2012 09:56:47 +0100
Message-ID: <CABP12JzdeFE=05KXe9PB3TYLzRcTqkW=0LOF1jsFX4Ai=2WuwQ@mail.gmail.com>
From: Francesco Fondelli <francesco.fondelli@gmail.com>
To: zhang.fei3@zte.com.cn
Content-Type: multipart/alternative; boundary="20cf303f67c67f79ae04b85bf5ed"
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: Tue, 07 Feb 2012 08:56:49 -0000

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