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

From: Lou Berger <[email-masked]>
Date: Thu, 02 Feb 2012 09:29:47 -0500

Fei,
	see below for responses in-line.

On 1/29/2012 4:49 AM, [email-masked] wrote:
> 
> 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.

Why not?  One of the purposes of this draft is to support non-recovery
uses of the association object.  Note the name of section 2.

> 
>     (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 ).

It's not clear to me what problem you're trying to solve.  Can you rephrase?

Also keep in mind that multiple association objects have always been
supported and this ability is not modified by the draft.

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

Yes.  This was discussed at the last IETF.  The WG previously had a
solution to this based on the association object, see rev 00 of the WG
document.  I removed it from the document based on discussion in Quebec.
 As discussed in Taipei the current rev can still be used to carry the
ITU-T identifiers (yes, the parts that were in -00 need to be separately
published to document this.)

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

Is there a question here?

Lou (as contributor)

> 
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: [email-masked]
Date: Fri, 3 Feb 2012 09:37:27 +0800

Lou

Thanks for your response, please see the reponses in-line with <fei></fei> 
to check whether I make a mistake.

Best regards 

Fei

Lou Berger <[email-masked]> 
2012-02-02 22:29

收件人
[email-masked]
抄送
"[email-masked]" <[email-masked]>
主题
Re: [CCAMP] Discussion on how to carry the Global_ID

Fei,

<Fei> 

According to my understanding, the association object is used to
associate different LSPs. See the descriptions in section 2:
"As described below,association is always done based on matching 
either Path state to Path state, or Resv state to Resv state" 

Consider the following scenairos:

               LSP1
A-------------------------------------------Z

Node A is located in AS1 and node Z is located in AS2, when the Path
message for LSP1 (co-routed bidirectinal LSP) with Extended Association
Object inserted is initiated at node A, three issues:

I1: what kind of association type is used here?

I2: association object is used across different path states, but LSP1
is not associated with any other LSPS in this case.

I3: Node A still does know the global ID of node Z

If these issues are really existed, the current usage of association 
object
should be revised, for example, like this:

R1: It can be used not to math path state, in other words, it can appear 
only
in one LSP's path message (no need to be pair)

R2: It can be used across Path and RESV state, in this way, an association 
object
can be inserted at node Z in the RESV message, with the global ID of node 
Z

R3: If issue 2 is agreeed, a new association type needs to be defined 
here?

</Fei>

> not know the gobal ID of Z9 node or Z9 nodes does not know the global ID

It's not clear to me what problem you're trying to solve.  Can you 
rephrase?

<fei>

Similarly with the issue 2 provided above, when LSP1 and LSP2 are bound 
together
to be an associated bidirectional LSP, the global ID carried in the LSP1's 
and
LSP2's Path messages are node A's or node Z's, if it is the global ID of 
node A,
node A still does know the global ID of node Z.

               LSP1
A-------------------------------------------Z
               LSP2 
Hope I clarify it clearly.  :)

</fei>

<fei> 
I agree
</fei>

<fei>
I agree, no problem here
</fei>

<fei>

If what I described in part 1 is reasonable, and the usage of association
object can be modified to cover these issues, there are no problem here
also.

</fei>

Lou (as contributor)

---

From: Vero Zheng <[email-masked]>
Date: Fri, 03 Feb 2012 10:02:50 +0000

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

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 ).

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.

Hope to hear the opinions from the WG that how to carry the Global_ID, then move the work forward.

Best regards

;)

Fei

---

From: [email-masked]
Date: Fri, 3 Feb 2012 22:35:50 +0800

Vero

Thanks for your response, see in line with <fei></fei>

Best regards

Fei

Vero Zheng <[email-masked]> 
2012-02-03 18:02

收件人
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送

主题
RE: [CCAMP] Discussion on how to carry the Global_ID

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>
 
Second, 
3. 

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>

Thanks.
 
Vero

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

    
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. 

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. 

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. 

Best regards 

;) 

Fei

---

From: Lou Berger <[email-masked]>
Date: Mon, 06 Feb 2012 10:54:07 -0500

Fei,
	See below.

On 2/2/2012 8:37 PM, [email-masked] wrote:
> 
> Lou
> 
> Thanks for your response, please see the reponses in-line with
> <fei></fei> to check whether I make a mistake.
> 
> Best regards
> 
> Fei
> 
> 
> *Lou Berger <[email-masked]>*
> 
> 2012-02-02 22:29
> 
> 	
> 收件人
> 	[email-masked]
> 抄送
> associate different LSPs. 

I agree that this is the original motivation for the association object.
 But if the need information is already defined for this object, why
define another object that carries the same information.  We certainly
can add some text to the draft to highlight this possibility.

> See the descriptions in section 2:

the same as you'd use in an associated by directional. Per your draft
this is type 4.  Your draft can make this clear; perhaps by renaming the
type to something along the lines of "LSP identification", and
explicitly covering this case.

> is not associated with any other LSPS in this case.

Strcikly speaking, for co-routed LSPs the association is per standard
RSVP and the association object is just carrying the LSP identification
information.

> I3: Node A still does know the global ID of node Z

Right, that has always come in the resv.

> If these issues are really existed, the current usage of association object

I think this is allowed, but certainly adding a few words to assoc-ext
to make this explicit is fine.

> R2: It can be used across Path and RESV state, in this way, an
> association object
> can be inserted at node Z in the RESV message, with the global ID of node Z
> 

Again, in the single LSP case, association is being made per standard RSVP.

> R3: If issue 2 is agreeed, a new association type needs to be defined here?
> 
Alternatively, just expand the scope/name of type 4 in your draft.

Lou

> to be an associated bidirectional LSP, the global ID carried in the
> LSP1's and

---

From: [email-masked]
Date: Tue, 7 Feb 2012 10:33:21 +0800

Lou

Perfect! I agree with your plan.

Best

Fei

2012-02-06 23:54

收件人
[email-masked]
抄送

Fei,
                 See below.

object

> can be inserted at node Z in the RESV message, with the global ID of 
node Z

Again, in the single LSP case, association is being made per standard 
RSVP.

here?

Lou

---

From: Vero Zheng <[email-masked]>
Date: Tue, 07 Feb 2012 07:33:00 +0000

Fei,

Please see in-line.

BR,
Vero

Fei,

you wrote:

First,

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

<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

Hi CCAMPers

Best regards

;)

Fei

---

From: [email-masked]
Date: Tue, 7 Feb 2012 16:29:38 +0800

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

2012-02-07 15:33

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: [CCAMP] Discussion on how to carry the Global_ID

Fei,
 
Please see in-line.
 
BR,
Vero
 
Fei, 
  
you wrote: 
  
First, 

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

  
<fei> 

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

Hi CCAMPers 

   

   (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. 

3. 

Best regards 

;) 

Fei

---

From: Francesco Fondelli <[email-masked]>
Date: Tue, 7 Feb 2012 09:56:47 +0100

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

>  *Vero Zheng <[email-masked]>*
>
> 2012-02-07 15:33
>   收件人
> Path/Resv message, and is not restricted either to co-routed bi-directional
> LSP or associated bi-directional LSP.
>
> <fei>
> receiver using the same C-Type of the object, i.e. both end using Global_ID
> or both using ICC_Operator_ID.
>
> Second,
> 3.
> (*Mis-Connectivity Defect*) of RFC6371.
>                   LSP1
>  *
> From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of [email-masked]*
> Sent:* Sunday, January 29, 2012 5:50 PM*
> To:* [email-masked]*
> Subject:* [CCAMP] Discussion on how to carry the Global_ID
>
>
> Hi CCAMPers
>
> with other LSPs. In these cases, the ASSOCIATION object will not be carried
> in the sigaling messages.
>
> not know the gobal ID of Z9 node or Z9 nodes does not know the global ID of
> A1 ).
>

---

From: [email-masked]
Date: Tue, 7 Feb 2012 17:29:29 +0800

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 <[email-masked]> 
2012-02-07 16:56

收件人
[email-masked]
抄送
Vero Zheng <[email-masked]>, "[email-masked]" <[email-masked]>
主题
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.

thank you
ciao
FF

Vero 

Regards 

Fei 

收件人

Fei, 
  
Please see in-line. 
  
BR, 
Vero 
  
Fei, 
 
you wrote: 
 
First, 

<fei> 
  
Second, 
3. 

 
<fei> 

</fei> 
  
BR, 
Vero 

Thanks. 
 
Vero 

Hi CCAMPers 

  

3. 

Best regards 

;) 

Fei

---

From: Francesco Fondelli <[email-masked]>
Date: Tue, 7 Feb 2012 14:14:18 +0100

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

> of expected MEP_ID and received MEP_ID, so A1 needs to pre-store the MEP_ID
> of Z9.
>
>  *Francesco Fondelli <[email-masked]>*
>
> 2012-02-07 16:56
>   收件人
> [email-masked]
> 抄送
> 2012/2/7 <[email-masked]* <[email-masked]>>
>
> Vero
>
>   *Vero Zheng <[email-masked]* <[email-masked]>*>*
>
> 2012-02-07 15:33
>
>   收件人
> "[email-masked]* <[email-masked]>" <[email-masked]*<[email-masked]>
> >
> 抄送
> "[email-masked]* <[email-masked]>" <[email-masked]* <[email-masked]>>
> 主题
> “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>
>
> 3. *
> *<http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01>
>
> From:* [email-masked]* <[email-masked]> [mailto:*
> [email-masked]* <[email-masked]>] *On Behalf Of **
> [email-masked]* <[email-masked]>*
> To:* [email-masked]* <[email-masked]>*
> 1.  *http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01*<http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01>
> .
>
> 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>
>
> 3. *
> *<http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01>
>
> CCAMP mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/ccamp*<https://www.ietf.org/mailman/listinfo/ccamp>
>
>
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 07 Feb 2012 08:34:20 -0500

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:
> 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.
> 
> 2012/2/7 <[email-masked] <mailto:[email-masked]>>
> 
> 
>     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.
> 
>     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.
>     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 <[email-masked] <mailto:[email-masked]>>*
> 
>     2012-02-07 15:33
> 
>     	
>     收件人
>     	"[email-masked] <mailto:[email-masked]>"
>     <[email-masked] <mailto:[email-masked]>>
>     抄送
>     	"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     主题
>     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.
> 
>     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>
>     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
>     (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
>     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:* [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] *On
>     Behalf Of [email-masked] <mailto:[email-masked]>*
>     To:* [email-masked] <mailto:[email-masked]>*
>     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.
> 
>     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 ).
> 
>     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.
>     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.
> 
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Francesco Fondelli <[email-masked]>
Date: Tue, 7 Feb 2012 15:07:16 +0100

Hi Lou,

I'm staring at those sections since last Wednesday.  Z9-Tunnel_Num
makes sense for associated bidi... but why we need it for signalling
bidi co-routed is still something I have to understand.  I'm sure it's
me missing something.

thanks
Ciao
FF

---

From: [email-masked]
Date: Wed, 8 Feb 2012 08:39:53 +0800

Francesco

See in line with <fei></fei>

Just my2cents

Best 

Fei

2012-02-07 21:14

收件人
[email-masked]
抄送

Hi,

<fei>
I just describe this usecase in the current draft, and the Z9-Tunnel_Num 
is OPTIONAL.
If we consider the service access at Z9 node, the index will be shorter, 
but it is related to the concrete realization. Furthermore, I am not sure 
whether it will have influence on the IGP ShortCut, need to think about 
it.
</fei> 

<fei> 
Actually, I pointed out this on the last IETF meeting presentation 
material,please check the following link:
http://tools.ietf.org/agenda/82/slides/ccamp-10.pdf
</fei>

<fei>
In the practical implementation, we can do this. But the Tunnel space is 
independent from each other at every node, which means that the 
conflicting will happen. 
</fei>

thanks
ciao
FF

Francesco 

Best regards 

Fei 

收件人
[email-masked] 
抄送

thank you
ciao
FF

Vero 

Regards 

Fei 

收件人

Fei, 
  
Please see in-line. 
  
BR, 
Vero 
  
Fei, 
 
you wrote: 
 
First, 

<fei> 
  
Second, 
3. 

 
<fei> 

</fei> 
  
BR, 
Vero 

Thanks. 
 
Vero 

Hi CCAMPers 

  

3. 

Best regards 

;) 

Fei

---

From: Mach Chen <[email-masked]>
Date: Wed, 08 Feb 2012 01:17:03 +0000

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-----
> Lou Berger
> Sent: Tuesday, February 07, 2012 9:34 PM
> To: Francesco Fondelli
> Cc: [email-masked]
> Subject: Re: [CCAMP] Discussion on how to carry the Global_ID
> 
> Francesco,

---

From: Lou Berger <[email-masked]>
Date: Wed, 08 Feb 2012 11:15:37 -0500

Mach,
	Sounds like a good discussion to have with the authors of RFC6370...

Lou

On 2/7/2012 8:17 PM, Mach Chen wrote:
> 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
>