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

[Vero Zheng <[e-mail]>]

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.

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?

Thanks.

Vero


From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Sunday, January 29, 2012 5:50 PM
To: [e-mail]
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