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

[Lou Berger <[e-mail]>]

Francesco,
	From my perspective, the (minimum) requirements are being driven by
rfc6370. Take a look at sections 5.2 and 5.3, and see if you still think
more mechanisms are being defined than is necessary.

Lou

On 2/7/2012 3:56 AM, Francesco Fondelli wrote:
> 
> Am I the only one here that feels "uncomfortable" with this approach and
> this additional Z9-Tunnel_Num index in GMPLS flying from egress to
> ingress (for no reason?!?)? It might be naive or even stupid but I'd
> like to understand why we have to add another index... please shed some
> light on me.
> 
> [I'm talking about co-routed bidi, I don't care about associated]
> 
> thank you
> ciao
> FF
> 
> 2012/2/7 <[e-mail] <mailto:[e-mail]>>
> 
> 
>     Vero
> 
>     Why is tunnel number not known by node A? The tunnel number should
>     has been carried in Session and Sender Template/Filter Spec object
>     and exchanged by node A and node Z during the LSP set-up. Correct me
>     if I am wrong.
> 
>     According to the description of RFC6370, section 5.1
>        At each end point, a tunnel is uniquely identified by the end point's
>       Node_ID and a locally assigned tunnel number.  Specifically, a
>       "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique
>       within the context of the Node_ID.  The motivation for each end point
>       having its own tunnel number is to allow a compact form for the
>       MEP_ID.
> 
>     Which means that for co-routed bidrectional LSP, there are two
>     tunnel numbers, one is locally assigned at node A and the other is
>     locally assigned at node Z.
>     If the signaling message is initialized at node A, the tunnel number
>     carried in Session/Sender Template objects is locally assigned at
>     node A. Of course, a new
>     C-type,like type=8, can be defined in the class of SESSION to carry
>     back the tunnel number assigned at node Z; but according to the
>     discussion with George, I do not think it is a good idea which is
>     not backward compatible.
> 
>     Regards
> 
>     Fei
> 
> 
>     *Vero Zheng <[e-mail] <mailto:[e-mail]>>*
> 
>     2012-02-07 15:33
> 
>     	
>     收件人
>     	"[e-mail] <mailto:[e-mail]>"
>     <[e-mail] <mailto:[e-mail]>>
>     抄送
>     	"[e-mail] <mailto:[e-mail]>" <[e-mail]
>     <mailto:[e-mail]>>
>     主题
>     	RE: [CCAMP] Discussion on how to carry the Global_ID
> 
> 
>     	
> 
> 
> 
> 
> 
>     Fei,
>      
>     Please see in-line.
>      
>     BR,
>     Vero
>      
>     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.
> 
>     <fei>
>     Although either co-routed or associated bidirectional LSP is not
>     mentioned in this draft , according to  the descripition in section
>     2.3, " If the node agrees, it MUST use the same format of Operator
>     ID.  The same C-Type of OIO MUST be carried in the Resv message",
>     which means that  the procedure is for corouted bidrectional LSP.
>     The above is just my understanding and provided for discussion, and
>     if it is wrong or inaccurate, please let me know.
>     </fei>
>     The procedure described above aims to guarantee the sender and the
>     receiver using the same C-Type of the object, i.e. both end using
>     Global_ID or both using ICC_Operator_ID.
>      
>     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?
>      
>     <fei>
>     As I said, it is useful for corouted (not associated) bidirectional
>     LSP,  consider that there is one LSP (LSP1, initiated at node A)
>     between node A/Z.
>     If the CC-V pakcet is  sent from  node Z, the MEP_ID of node Z will
>     be inserted in the OAM packets, which is organized by
>     node_ID::tunnel_num::LSP_num
>     (section 5.2.1 or 7.2.2 of RFC6370), and if this MEP_ID is not
>     pre-stored at node A, it can not judge whether this MEP_ID is valid.
>     See the description in section 5.1.1.2
>     (*Mis-Connectivity Defect*) of RFC6371.
>                       LSP1
>     A-------------------------------Z
> 
> 
>     </fei>
>     Why is tunnel number not known by node A? The tunnel number should
>     has been carried in Session and Sender Template/Filter Spec object
>     and exchanged by node A and node Z during the LSP set-up. Correct me
>     if I am wrong.
>      
>     BR,
>     Vero
> 
>     Thanks.
>      
>     Vero
>      
>      *
>     From:* [e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail] <mailto:[e-mail]>] *On
>     Behalf Of *[e-mail] <mailto:[e-mail]>*
>     Sent:* Sunday, January 29, 2012 5:50 PM*
>     To:* [e-mail] <mailto:[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
> 
>     _______________________________________________
>     CCAMP mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp