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

Lou Berger <lberger@labn.net> Thu, 02 February 2012 14:29 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 A6C4C21F84DD for <ccamp@ietfa.amsl.com>; Thu, 2 Feb 2012 06:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.286
X-Spam-Level:
X-Spam-Status: No, score=-98.286 tagged_above=-999 required=5 tests=[AWL=1.875, 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 AJqhRXQkfGCp for <ccamp@ietfa.amsl.com>; Thu, 2 Feb 2012 06:29:48 -0800 (PST)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 761C521F8467 for <ccamp@ietf.org>; Thu, 2 Feb 2012 06:29:47 -0800 (PST)
Received: (qmail 9913 invoked by uid 0); 2 Feb 2012 14:29:46 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 2 Feb 2012 14:29:46 -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=5UX/Cv7MmdnxnWquK+R73/VcG1vBMgykOWbOg3zO1rI=; b=cuSPlojM7Grlz0e+ofyvfUG+oUNtt76IBLzGofT/cGAJlPwjQl0IeACCpLDw/O+FDmY2nz94sMaQUnTOwNO4+dkM9peMH339SXZVNqIeXwDS/8PRKQo57/aqHKdnSOla;
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 1RsxfW-0001BL-D7; Thu, 02 Feb 2012 07:29:46 -0700
Message-ID: <4F2A9DDB.3040700@labn.net>
Date: Thu, 02 Feb 2012 09:29:47 -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: zhang.fei3@zte.com.cn
References: <OF1AC6F5A8.FDB55617-ON48257994.002E93FB-48257994.0035F876@zte.com.cn>
In-Reply-To: <OF1AC6F5A8.FDB55617-ON48257994.002E93FB-48257994.0035F876@zte.com.cn>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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: Thu, 02 Feb 2012 14:29:48 -0000

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.

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

Also keep in mind that multiple association objects have always been
supported and this ability is not modified by the draft.

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

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

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