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

[Mach Chen <[e-mail]>]

Hi Lou,

I am always assume that the Z9-tunnel-num equals to A1-tunnel-num (for co-routed bidirectional LSP). The motivation (from the text of RFC6370 and the past discussion on MPLS-TP identifier) of two tunnel-nums is for simplifying associated bidirectional signaling, for co-routed bidirectional LSP, two tunnel-nums are unnecessary. If I am wrong, please correct me.(cc MPLS WG)

IMHO, the simplest way is to explicitly clarify that for co-routed bidirectional LSP, A1-tunnel-num=Z9-tunnel-num, maybe a clarification errata is needed for RFC6370.

Best regards,
Mach

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Lou Berger
> Sent: Tuesday, February 07, 2012 9:34 PM
> To: Francesco Fondelli
> Cc: [e-mail]
> Subject: Re: [CCAMP] Discussion on how to carry the Global_ID
> 
> 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-0
> 1
> >
> >
> >     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-0
> 1
> >
> >
> >     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
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp