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

[Lou Berger <[e-mail]>]

Fei,
	see below for responses in-line.

On 1/29/2012 4:49 AM, [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp