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

Francesco Fondelli <francesco.fondelli@gmail.com> Tue, 07 February 2012 14:07 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 2240021F87C7 for <ccamp@ietfa.amsl.com>; Tue, 7 Feb 2012 06:07:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.111
X-Spam-Level:
X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, 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 gzVIR72MSUZR for <ccamp@ietfa.amsl.com>; Tue, 7 Feb 2012 06:07:17 -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 F11AC21F86B3 for <ccamp@ietf.org>; Tue, 7 Feb 2012 06:07:16 -0800 (PST)
Received: by yhkk25 with SMTP id k25so3407020yhk.31 for <ccamp@ietf.org>; Tue, 07 Feb 2012 06:07:16 -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:content-transfer-encoding; bh=9qbW0yjefF9trdtm4NRJQucfmrCg8G2eGbslL35lD8U=; b=AxAMWWq+Tcy1v5GabPiJJ0hSTYbg5KrYSsvYL4rwzBV6lC2CSFoCA2ZdUmS6SyYK2h vaQDq+sYUyl9isAx0/CNlldD1Xzs/nvkN3R8o85eaGOJ//75a86ZPCe7tUUglgq8sweD uuxMX9xv/K0tNGTCInbdwvFyMOs7T0nK6fmoA=
MIME-Version: 1.0
Received: by 10.236.173.202 with SMTP id v50mr32243891yhl.102.1328623636620; Tue, 07 Feb 2012 06:07:16 -0800 (PST)
Received: by 10.236.155.103 with HTTP; Tue, 7 Feb 2012 06:07:16 -0800 (PST)
In-Reply-To: <4F31285C.6040107@labn.net>
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>
Date: Tue, 7 Feb 2012 15:07:16 +0100
Message-ID: <CABP12JyzZ49bPxr7zAZo2PL5+c9ERNiZ8+T-mes5UtT7gJD1Pw@mail.gmail.com>
From: Francesco Fondelli <francesco.fondelli@gmail.com>
To: Lou Berger <lberger@labn.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 14:07:18 -0000

Hi Lou,

I'm staring at those sections since last Wednesday.  Z9-Tunnel_Num
makes sense for associated bidi... but why we need it for signalling
bidi co-routed is still something I have to understand.  I'm sure it's
me missing something.

thanks
Ciao
FF

On Tue, Feb 7, 2012 at 2:34 PM, Lou Berger <lberger@labn.net> wrote:
> 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-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>
>>     [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-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 <mailto:CCAMP@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp