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

[Francesco Fondelli <[e-mail]>]

Hi,

if this is the only use case I strongly suggest you to make anything
related to Z9-Tunnel_Num OPTIONAL in signaling (dunno if this is the case
in your I-D). Please.

BTW, I'm wondering... if this is just about MEP ID what's the relation of
your I-D and this one:

http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-07

Why not simply assume that A1-Tunnel_Num == Z9-Tunnel_Num ? (for co-routed
bidi) and leave GMPLS in peace?

thanks
ciao
FF

2012/2/7 <[e-mail]>

>
> Francesco
>
> Below is one usecase based on my understanding.
>
> A1----------------Z9 (co-routed)
>
> The MEP_ID of A1 is A1:Global_ID::Node_ID::Tunnel_Num::LSP_Num, similarly
> the MEP_ID of Z9 is Z9:Global_ID::Node_ID::Tunnel_Num::LSP_Num.
>
> Consider that CC-V packets are sent from Z9 to A1, MEP_ID of Z9 is
> inserted in the CC-V packets.
>
> The Mis-Connectivity Defect (RFC6371) is declared based on the comparison
> of expected MEP_ID and received MEP_ID, so A1 needs to pre-store the MEP_ID
> of Z9.
>
> For static LSP, the exchanges of LSP identifers can be realized by the GAP
> (G-ACh Advertisement Protocol) protocol defined in the draft
> http://tools.ietf.org/html/draft-ietf-mpls-gach-adv-00. As to dynamically
> established LSP, which can be carried in the signaling message.
>
> I am not sure whether the interpretation is reasonable to you.
>
> Best regards
>
> Fei
>
>
>  *Francesco Fondelli <[e-mail]>*
>
> 2012-02-07 16:56
>   收件人
> [e-mail]
> 抄送
> Vero Zheng <[e-mail]>, "[e-mail]" <[e-mail]>
> 主题
> Re: [CCAMP] Discussion on how to carry the Global_ID
>
>
>
>
>
> 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]* <[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]* <[e-mail]>*>*
>
> 2012-02-07 15:33
>
>   收件人
> "*[e-mail]* <[e-mail]>" <*[e-mail]*<[e-mail]>
> >
> 抄送
> "*[e-mail]* <[e-mail]>" <*[e-mail]* <[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*<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
> *<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]* <[e-mail]> [mailto:*
> [e-mail]* <[e-mail]>] *On Behalf Of **
> [e-mail]* <[e-mail]>*
> Sent:* Sunday, January 29, 2012 5:50 PM*
> To:* *[e-mail]* <[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*<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*<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
> *<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]* <[e-mail]>*
> **https://www.ietf.org/mailman/listinfo/ccamp*<https://www.ietf.org/mailman/listinfo/ccamp>
>
>
>