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

[[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]>

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]> 
2012-02-07 15:33 


收件人
"[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 

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]] 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 

_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp