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

zhang.fei3@zte.com.cn Tue, 07 February 2012 02:33 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 5830411E80BB for <ccamp@ietfa.amsl.com>; Mon, 6 Feb 2012 18:33:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.806
X-Spam-Level:
X-Spam-Status: No, score=-96.806 tagged_above=-999 required=5 tests=[AWL=-0.929, 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 114omw34xTWn for <ccamp@ietfa.amsl.com>; Mon, 6 Feb 2012 18:33:48 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8393811E80BE for <ccamp@ietf.org>; Mon, 6 Feb 2012 18:33:35 -0800 (PST)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690473195744; Tue, 7 Feb 2012 10:06:56 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 83373.984958751; Tue, 7 Feb 2012 10:33:26 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q172XNFw091721; Tue, 7 Feb 2012 10:33:23 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn)
In-Reply-To: <4F2FF79F.5010004@labn.net>
To: Lou Berger <lberger@labn.net>
MIME-Version: 1.0
X-KeepSent: D78E7382:AEEC0EC1-4825799D:000D883E; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OFD78E7382.AEEC0EC1-ON4825799D.000D883E-4825799D.000E0A9F@zte.com.cn>
From: zhang.fei3@zte.com.cn
Date: Tue, 7 Feb 2012 10:33:21 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-07 10:33:24, Serialize complete at 2012-02-07 10:33:24
Content-Type: multipart/alternative; boundary="=_alternative 000E0A9F4825799D_="
X-MAIL: mse01.zte.com.cn q172XNFw091721
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 02:33:49 -0000

Lou

Perfect! I agree with your plan.

Best

Fei



Lou Berger <lberger@labn.net> 
2012-02-06 23:54

收件人
zhang.fei3@zte.com.cn
抄送
"ccamp@ietf.org" <ccamp@ietf.org>
主题
Re: [CCAMP] Discussion on how to carry the Global_ID






Fei,
                 See below.

On 2/2/2012 8:37 PM, zhang.fei3@zte.com.cn wrote:
> 
> Lou
> 
> Thanks for your response, please see the reponses in-line with
> <fei></fei> to check whether I make a mistake.
> 
> Best regards
> 
> Fei
> 
> 
> *Lou Berger <lberger@labn.net>*
> 
> 2012-02-02 22:29
> 
> 
> 收件人
>                zhang.fei3@zte.com.cn
> 抄送
>                "ccamp@ietf.org" <ccamp@ietf.org>
> 主题
>                Re: [CCAMP] Discussion on how to carry the Global_ID
> 
> 
> 
> 
> 
> 
> 
> 
> Fei,
>                 see below for responses in-line.
> 
> On 1/29/2012 4:49 AM, zhang.fei3@zte.com.cn wrote:
>>
>> 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.
> 
> Why not?  One of the purposes of this draft is to support non-recovery
> uses of the association object.  Note the name of section 2.
> 
> <Fei>
> 
> According to my understanding, the association object is used to
> associate different LSPs. 

I agree that this is the original motivation for the association object.
 But if the need information is already defined for this object, why
define another object that carries the same information.  We certainly
can add some text to the draft to highlight this possibility.

> See the descriptions in section 2:
> "As described below,association is always done based on matching
> either Path state to Path state, or Resv state to Resv state"
> 
> Consider the following scenairos:
> 
>                LSP1
> A-------------------------------------------Z
> 
> Node A is located in AS1 and node Z is located in AS2, when the Path
> message for LSP1 (co-routed bidirectinal LSP) with Extended Association
> Object inserted is initiated at node A, three issues:
> 
> I1: what kind of association type is used here?

the same as you'd use in an associated by directional. Per your draft
this is type 4.  Your draft can make this clear; perhaps by renaming the
type to something along the lines of "LSP identification", and
explicitly covering this case.

> 
> I2: association object is used across different path states, but LSP1
> is not associated with any other LSPS in this case.

Strcikly speaking, for co-routed LSPs the association is per standard
RSVP and the association object is just carrying the LSP identification
information.

> 
> I3: Node A still does know the global ID of node Z
> 

Right, that has always come in the resv.

> If these issues are really existed, the current usage of association 
object
> should be revised, for example, like this:
> 
> R1: It can be used not to math path state, in other words, it can appear
> only
> in one LSP's path message (no need to be pair)
> 

I think this is allowed, but certainly adding a few words to assoc-ext
to make this explicit is fine.

> R2: It can be used across Path and RESV state, in this way, an
> association object
> can be inserted at node Z in the RESV message, with the global ID of 
node Z
> 

Again, in the single LSP case, association is being made per standard 
RSVP.

> R3: If issue 2 is agreeed, a new association type needs to be defined 
here?
> 
Alternatively, just expand the scope/name of type 4 in your draft.

Lou

> </Fei>
> 
> 
>>
>>     (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 ).
> 
> It's not clear to me what problem you're trying to solve.  Can you
> rephrase?
> 
> <fei>
> 
> Similarly with the issue 2 provided above, when LSP1 and LSP2 are bound
> together
> to be an associated bidirectional LSP, the global ID carried in the
> LSP1's and
> LSP2's Path messages are node A's or node Z's, if it is the global ID of
> node A,
> node A still does know the global ID of node Z.
> 
>                LSP1
> A-------------------------------------------Z
>                LSP2
> Hope I clarify it clearly.  :)
> 
> </fei>
> 
> 
> Also keep in mind that multiple association objects have always been
> supported and this ability is not modified by the draft.
> 
> <fei>
> I agree
> </fei>
> 
>>
>> 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.
> 
> Yes.  This was discussed at the last IETF.  The WG previously had a
> solution to this based on the association object, see rev 00 of the WG
> document.  I removed it from the document based on discussion in Quebec.
> As discussed in Taipei the current rev can still be used to carry the
> ITU-T identifiers (yes, the parts that were in -00 need to be separately
> published to document this.)
> 
> <fei>
> I agree, no problem here
> </fei>
> 
>>
>> 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.
> 
> Is there a question here?
> 
> <fei>
> 
> If what I described in part 1 is reasonable, and the usage of 
association
> object can be modified to cover these issues, there are no problem here
> also.
> 
> </fei>
> 
> Lou (as contributor)
> 
>>
>>
>> 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
> 
>