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

Lou Berger <lberger@labn.net> Tue, 07 February 2012 13:34 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 1B5FE21F8627 for <ccamp@ietfa.amsl.com>; Tue, 7 Feb 2012 05:34:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.377
X-Spam-Level:
X-Spam-Status: No, score=-98.377 tagged_above=-999 required=5 tests=[AWL=1.784, 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 G77V11GTKQ0R for <ccamp@ietfa.amsl.com>; Tue, 7 Feb 2012 05:34:24 -0800 (PST)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 13B9F21F85C4 for <ccamp@ietf.org>; Tue, 7 Feb 2012 05:34:23 -0800 (PST)
Received: (qmail 17242 invoked by uid 0); 7 Feb 2012 13:34:23 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 7 Feb 2012 13:34:23 -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=ptQKeMDo3vCWjH5UQ4p1Ai1GDuTPmbwxfP3bErRn52Y=; b=BBYNDTcEXwsbfy80ZQ01HNbXdFHY1jHZu80fJ+oI9vbxHkWxuO4fm40++ujy+RnB5SD7fkR5Yfdc7MLVJU8hlO0p8flmm/lKtVDvPF1GV9bFN7t5aZAZ/Oo5Klh4azz3;
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 1RulBe-0003tK-Vl; Tue, 07 Feb 2012 06:34:23 -0700
Message-ID: <4F31285C.6040107@labn.net>
Date: Tue, 07 Feb 2012 08:34:20 -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: Francesco Fondelli <francesco.fondelli@gmail.com>
References: <2EEA459CD95CCB4988BFAFC0F2287B5C25917498@SZXEML520-MBS.china.huawei.com> <OF8234A400.3AFAFF34-ON4825799D.002C2EA9-4825799D.002EA8F1@zte.com.cn> <CABP12JzdeFE=05KXe9PB3TYLzRcTqkW=0LOF1jsFX4Ai=2WuwQ@mail.gmail.com>
In-Reply-To: <CABP12JzdeFE=05KXe9PB3TYLzRcTqkW=0LOF1jsFX4Ai=2WuwQ@mail.gmail.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: "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 13:34:25 -0000

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