[CCAMP] Discussion on how to carry the Global_ID

zhang.fei3@zte.com.cn Sun, 29 January 2012 09:49 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 37F4021F847A for <ccamp@ietfa.amsl.com>; Sun, 29 Jan 2012 01:49:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.992
X-Spam-Status: No, score=-99.992 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6b4onu-5TcfZ for <ccamp@ietfa.amsl.com>; Sun, 29 Jan 2012 01:49:55 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn []) by ietfa.amsl.com (Postfix) with ESMTP id 12D0B21F8478 for <ccamp@ietf.org>; Sun, 29 Jan 2012 01:49:54 -0800 (PST)
Received: from [] by mx5.zte.com.cn with surfront esmtp id 56690473195744; Sun, 29 Jan 2012 17:25:07 +0800 (CST)
Received: from [] by [] with StormMail ESMTP id 45375.473195744; Sun, 29 Jan 2012 17:49:49 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([]) by mse02.zte.com.cn with ESMTP id q0T9niR7058965 for <ccamp@ietf.org>; Sun, 29 Jan 2012 17:49:44 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn)
To: "ccamp@ietf.org" <ccamp@ietf.org>
MIME-Version: 1.0
X-KeepSent: 1AC6F5A8:FDB55617-48257994:002E93FB; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF1AC6F5A8.FDB55617-ON48257994.002E93FB-48257994.0035F876@zte.com.cn>
From: zhang.fei3@zte.com.cn
Date: Sun, 29 Jan 2012 17:49:35 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-29 17:49:48, Serialize complete at 2012-01-29 17:49:48
Content-Type: multipart/alternative; boundary="=_alternative 0035F86F48257994_="
X-MAIL: mse02.zte.com.cn q0T9niR7058965
Subject: [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: Sun, 29 Jan 2012 09:49:56 -0000


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.

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