Subject: [CCAMP] poll on making draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 a WG document

From: Lou Berger <[email-masked]>
Date: Mon, 21 May 2012 08:46:42 -0400

All,

This is to start a two week poll on making
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 a ccamp working
group document. Please send mail to the list indicating "yes/support"
or "no/do not support".  If indicating no, please state your technical
reservations with the document.

The poll ends Monday June 4.

Please note that this document aims to satisfy certain MPLS-TP
requirements that the WG has identified as part of RFC6373.

Much thanks,
Lou (and Deborah)

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 21 May 2012 21:26:58 +0100

Hi,

<Not wearing any hats :->

I think this document needs some more work before we can work out what it is
trying to achieve.

The abstract contains a healthy paragraph saying that both MEPs need to exchange
MEP_IDs so that OAM works. I expected that function to be found in
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext (unless it can be generalized for
inclusion in draft-ietf-ccamp-oam-configuration-fwk).

Also, looking at RFC 6370, it is unclear that any work is actually needed.

But, the second short paragraph of the abstract says that this I-D enables the
exchange of LSP identifiers. Of course, RFC 3209 has some quite good mechanisms
for that :-)

So, reading on...

The document also seems to propose the use of the Association object to carry
this information (whatever it is). I don't think this is an appropriate use of
this object - it is intended to associate LSPs with each other, not as a way of
carrying additional information. *If* the problem arises because of a pair of
associated LSPs that form a single bidirectional LSP service, then surely the
solution belongs in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp.

Thus, my conclusion is that if this work is needed, it belongs distributed
across the I-Ds I mention, and not in its own document.

Thanks,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Lou Berger
> Sent: 21 May 2012 13:47
> To: [email-masked]
> Subject: [CCAMP] poll on making draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-
> num-02 a WG document
> 
> All,
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

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

Hi Adrian

Thanks for your comments, another thread is opened for the convenient 
discussion, see my response in line with <fei></fei>

Best regards

Fei

"Adrian Farrel" <[email-masked]> 
发件人:  [email-masked]
2012-05-22 04:26
请答复 给
[email-masked]

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

主题
Re: [CCAMP] poll on     making 
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 a    WG document

Hi,

I think this document needs some more work before we can work out what it 
is
trying to achieve.

The abstract contains a healthy paragraph saying that both MEPs need to 
exchange
MEP_IDs so that OAM works. I expected that function to be found in
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext (unless it can be generalized for
inclusion in draft-ietf-ccamp-oam-configuration-fwk).

<fei>
The establishment of OAM entities and functions are described in Section 
3.1 of the draft draft-ietf-ccamp-oam-configuration-fwk, which said
that "In the case of bidirectional connections....  Depending on the OAM 
technology, some elements of the OAM Configuration TLV MAY be 
updated/changed; i.e., if the remote end is not supporting a certain OAM 
configuration it may suggest an alternative setting, which may or may not 
be accepted by the initiator of the Path message". Since this framework 
document is aimed to cover Ethernet/SDH/SONET/OTN/MPLS-TP, and each 
technology has different definition of the MEP_ID,
this function may be not suitable to be covered by this document.

As to the document draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext, it said in 
section 3.2 "Hence, the following mapping is used without the need of 
redefining a
new TLV for MPLS-TP proactive CV purpose." According to my understanding, 
Global_ID and Z9-LSP_Num is needed for configuring the MEP function
of co-routed bidirectional LSP. Furthermore, this draft does not cover the 
usecase of associated bidirectional LSP.
</fei>

<fei>
The Global_ID and Z9-LSP_Num (corouted bidirectional LSP) are introduced 
in RFC6370, which are the parts of the MEP_ID. :-)
</fei>

But, the second short paragraph of the abstract says that this I-D enables 
the
exchange of LSP identifiers. Of course, RFC 3209 has some quite good 
mechanisms
for that :-)

<fei>
Sorry for the error description, it should be the exchange of the MEP_ID, 
which will be revised in the next version.
The LSP identifiers are the combination of MEP_ID, like 
A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num (assoicated)
or A1-{Node_ID::Tunnel_Num::LSP_Num}:: Z9-{Node_ID::Tunnel_Num::LSP_Num} 
(co-routed)
</fei>

So, reading on...

The document also seems to propose the use of the Association object to 
carry
this information (whatever it is). I don't think this is an appropriate 
use of
this object - it is intended to associate LSPs with each other, not as a 
way of
carrying additional information. 

<fei>
As described in the draft draft-ietf-ccamp-assoc-ext-03, section 2 said 
that "Note that there are times when no matching state is found, e.g., 
when processing an initial LSP or when the ASSOCIATION object contains 
otherwise useful information" or "The use of an ASSOCIATION object in a 
single session is not precluded". My understanding is that the ASSOCIATION 
object can be used as a way of carrying additional information, in fact, 
the corouted bidirectional LSP can be seen as two connected unidirectional 
LSPs, see RFC6370, "At the data-plane level, a co-routed bidirectional LSP 
is composed of two unidirectional LSPs traversing the same links in 
opposite directions." 
</fei>

*If* the problem arises because of a pair of
associated LSPs that form a single bidirectional LSP service, then surely 
the
solution belongs in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp.

<fei>
No, it is a generalized scheme for both corouted and associated 
bidirectional LSPs.
</fei>

Thanks,
Adrian

> Subject: [CCAMP] poll on making 
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-

---

From: [email-masked]
Date: Wed, 23 May 2012 20:28:00 +0800

yes/support

As an author

Best

Fei

Lou Berger <[email-masked]> 
发件人:  [email-masked]
2012-05-21 20:46

收件人
[email-masked]
抄送

主题
[CCAMP] poll on making  draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 
a WG document

All,

Much thanks,
Lou (and Deborah)

---

From: Mach Chen <[email-masked]>
Date: Thu, 24 May 2012 01:29:26 +0000

Hi,

I have a question here, the draft seems to extends RSVP-TE to carry the Global_ID and tunnel_num, I remember that draft-ietf-ccamp-assoc-ext has already defined how to carry the Global_ID, and RFC 3209 and RFC 3473 have defined how to carry the Tunnel_Num. Why we need another draft to do this again?

Many thanks,
Mach

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Lou Berger
> Sent: Monday, May 21, 2012 8:47 PM
> To: [email-masked]

---

From: [email-masked]
Date: Thu, 24 May 2012 10:20:41 +0800

Hi, Mach

Another thread is opened here for discussion.

Consider the following example, a co-routed bidirectional LSP1 is across 
from A1 to Z9

A1-----LSP1--------Z9

Problem statement:

According to RFC6371, The CV function needs the MEP nodes to compare the 
received and expected MEP-IDs to judge whether there is a mismatch.

So my understandingt is that A1 and Z9 nodes need to pre-store each 
other's MEP_ID before the CV packets are sent out.
 
RFC6370 said that the MEP_ID of A1 node is A1-{
Global_ID::Node_ID::Tunnel_Num::LSP_Num}, and similarly the MEP_ID of Z9 
node is
Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}. Keep in mind that the 
Global_ID and Tunnel_Num may be different at the two nodes.

As to the question why the tunnel_Num is different that you asked on 
February, see the thread
http://www.ietf.org/mail-archive/web/ccamp/current/msg13079.html. From my 
implementation experience, two reasons are listed here:
(1)The tunnel spaces may be divided into different usage. For example, one 
parts for the normal tunnels and one parts for the backup tunnels. That is 
to say,
T1 in node A1 may be used for the normal tunnel and T1 is node Z9 may be 
used for bakcup tunnel.
(2) If the tunnel_num MUST keep the same in node A1 and node Z9, the 
blocking probability will be higher since the required tunnel may be 
already occupied on 
the Z9 node.

As listed above, different tunnel_nums on the two end points are 
convenient for interoperability and implementation, my2cents. 

Gaps:

The Global_ID used in the draft draft-ietf-ccamp-assoc-ext may be A1's or 
Z9's, if it is A1's Global_ID, A1 still does not know the Global_ID of Z9.

RFC 3209 and RFC 3473 just define the tunnel_num of A1, the tunnel_num of 
Z9 is not specified.

For clarification, all these information are already defined in the 
ASSOCIATION object, see the draft draft-ietf-ccamp-assoc-ext. This draft 
just defines one new Association type for the exchange of each other's 
MEP_ID in case of co-routed and associated bidirectional LSPs scenarios.

Hope clarify what is the motivation of this draft.

Best regards

Fei

Mach Chen <[email-masked]> 
发件人:  [email-masked]
2012-05-24 09:29

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

主题

Hi,

I have a question here, the draft seems to extends RSVP-TE to carry the 
Global_ID and tunnel_num, I remember that draft-ietf-ccamp-assoc-ext has 
already defined how to carry the Global_ID, and RFC 3209 and RFC 3473 have 
defined how to carry the Tunnel_Num. Why we need another draft to do this 
again?

Many thanks,
Mach

---

From: Mach Chen <[email-masked]>
Date: Thu, 24 May 2012 03:33:38 +0000

Hi Fei,

Please see my response inline...

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, May 24, 2012 10:21 AM
> To: Mach Chen
> Cc: [email-masked]; [email-masked]; Lou Berger
> Subject: Re: [CCAMP] poll on making
> draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 a WG
> document//discussion
> 
> 
> Hi, Mach
> 
> According to RFC6371, The CV function needs the MEP nodes to compare
> the received and expected MEP-IDs to judge whether there is a mismatch.
> 
> RFC6370 said that the MEP_ID of A1 node is
> A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}, and similarly the
> MEP_ID of Z9 node is
> http://www.ietf.org/mail-archive/web/ccamp/current/msg13079.html.
> From my implementation experience, two reasons are listed here:
> (1)The tunnel spaces may be divided into different usage. For example,
> one parts for the normal tunnels and one parts for the backup tunnels.
> That is to say,
> T1 in node A1 may be used for the normal tunnel and T1 is node Z9 may
> be used for bakcup tunnel.

The "Global Association Source" field should carry the Global_ID of the node who sends the Extended ASSOCIATION Object, if A1 sends, then Z9 learns the ID of A1's, and vice versa. 

If Z9 send Path or RESV message to A1, why can A1 not learn Z9's ID?

> 
> RFC 3209 and RFC 3473 just define the tunnel_num of A1, the
> tunnel_num of Z9 is not specified.

For co-routed bidirectional LSP, as defined in RFC3473, there is only ONE tunnel_num, so the Z9-tunnel_num should be the same as the A1-tunnel_num. 

For associated bidirectional LSP that is actually combined by two unidirectional LSPs , it already has two tunnel_nums that could map to A1 and Z9-tunnel_num respectively.

So, no need to define extra mechanisms to communicate the tunnel_num, existing mechanisms are enough. 

> MEP_ID in case of co-routed and associated bidirectional LSPs scenarios.

One of the motivations of Extended ASSOCIATION Object is for carrying MPLS-TP global identifier, and draft draft-ietf-ccamp-assoc-ext is still working in progress, if you think the current text is not clear on the TP global identifier usage, IMHO, the best way is to comment and enhance that draft. 

Best regards,
Mach

> Re: [CCAMP] poll
> on        making        draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunn
> el-num-02 a        WG document
> 
> 
> 
> 
> 
> 
> 
> Hi,
> 
> Global_ID and tunnel_num, I remember that draft-ietf-ccamp-assoc-ext
> has already defined how to carry the Global_ID, and RFC 3209 and RFC
> 3473 have defined how to carry the Tunnel_Num. Why we need another
> draft to do this again?
> 
> Many thanks,
> Mach
>

---

From: [email-masked]
Date: Thu, 24 May 2012 12:44:00 +0800

Mach, see in line with <fei></fei>

Best

Fei

2012-05-24 11:33

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, Lou Berger <[email-masked]>
主题
RE: [CCAMP] poll on making 
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 a WG 
document//discussion

Hi Fei,

> Z9's, if it is A1's Global_ID, A1 still does not know the Global_ID of 
Z9.

The "Global Association Source" field should carry the Global_ID of the 
node who sends the Extended ASSOCIATION Object, if A1 sends, then Z9 
learns the ID of A1's, and vice versa. 

<fei>
Of course it can, but the information carried in the ASSOCIATION object is 
changed, so a new association type is defined here to allow this usage, 
and the
procedure is also described in the draft, please check it.
</fei>

> tunnel_num of Z9 is not specified.

For co-routed bidirectional LSP, as defined in RFC3473, there is only ONE 
tunnel_num, so the Z9-tunnel_num should be the same as the A1-tunnel_num. 

<fei>
The MPLS-TP standards appear after RFC3473, or before that, and the 
co-routed bidrectional LSP needs to address the new requirements.
</fei>

For associated bidirectional LSP that is actually combined by two 
unidirectional LSPs , it already has two tunnel_nums that could map to A1 
and Z9-tunnel_num respectively.

<fei>
Agree, the draft actually uses the Z9-tunnel_num, please check this point.
</fei>

So, no need to define extra mechanisms to communicate the tunnel_num, 
existing mechanisms are enough. 

<fei>
See above
</fei>

> MEP_ID in case of co-routed and associated bidirectional LSPs scenarios.

One of the motivations of Extended ASSOCIATION Object is for carrying 
MPLS-TP global identifier, and draft draft-ietf-ccamp-assoc-ext is still 
working in progress, if you think the current text is not clear on the TP 
global identifier usage, IMHO, the best way is to comment and enhance that 
draft. 

<fei>
As I commented and contributed in the past that the draft 
draft-ietf-ccamp-assoc-ext is clear on the TP global identifiers usages. 
Since the draft draft-ietf-ccamp-assoc-ext just defines the general usage 
of the ASSOCIATION object and does not cover the association type specific 
rules,
here the associaiton type "LSP Identifiers" needs the ASSOCIATION to 
appear in a single session, and the ASSOCIATION can be different. I am not 
sure it is suitable to be addressed in that document, anyway it is up to 
WG's decision.
Please check the thread 
http://www.ietf.org/mail-archive/web/ccamp/current/msg12014.html for more 
information
</fei>

</fei>
Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Thu, 24 May 2012 06:30:53 +0000

Hi Fei,

For exchanging Global_ID, it’s simple and straightforward, and Extended ASSOCIATION Object is mainly designed for it, IMHO, it should belong to draft-ietf-ccamp-assoc-ext.

For tunnel_num, the only confusion is the Z9-tunnel_num for co-routed bidirectional LSP which is introduced by RFC 6370, but IMHO, it’s unnecessary, especially when the LSP is signaled dynamically. If Z9-tunnel_num needed, does it mean Z9-LSP_num is also needed? In addition, did anyone find any issues when implement RFC3473?

As discussed with Lou several months ago on the same issue, the best way is to update( or an errata)  RFC6370 to clarify that : for co-routed bidirectional LSP, A1-tunnel_num is the same as Z9-tunnel_num.

Best regards,
Mach

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 24, 2012 12:44 PM
To: Mach Chen
Cc: [email-masked]; [email-masked]; Lou Berger
Subject: RE: [CCAMP] poll on making draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 a WG document//discussion

Best

Fei

2012-05-24 11:33

收件人

抄送

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Lou Berger <[email-masked]>

主题

RE: [CCAMP] poll on making draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 a WG document//discussion

Hi Fei,

<fei>
Of course it can, but the information carried in the ASSOCIATION object is changed, so a new association type is defined here to allow this usage, and the
procedure is also described in the draft, please check it.
</fei>

<fei>
The MPLS-TP standards appear after RFC3473, or before that, and the co-routed bidrectional LSP needs to address the new requirements.
</fei>

<fei>

<fei>
See above
</fei>

<fei>
As I commented and contributed in the past that the draft draft-ietf-ccamp-assoc-ext is clear on the TP global identifiers usages.
Since the draft draft-ietf-ccamp-assoc-ext just defines the general usage of the ASSOCIATION object and does not cover the association type specific rules,
here the associaiton type "LSP Identifiers" needs the ASSOCIATION to appear in a single session, and the ASSOCIATION can be different. I am not sure it is suitable to be addressed in that document, anyway it is up to WG's decision.
Please check the thread http://www.ietf.org/mail-archive/web/ccamp/current/msg12014.html for more information
</fei>

</fei>
Best regards,
Mach

---

From: [email-masked]
Date: Thu, 24 May 2012 15:25:03 +0800

Hi Mach

See in line with <fei></fei>

Best

Fei

2012-05-24 14:30

收件人

Hi Fei,
 
For exchanging Global_ID, it’s simple and straightforward, and Extended 
ASSOCIATION Object is mainly designed for it, IMHO, it should belong to 
draft-ietf-ccamp-assoc-ext. 

 <fei>
I have explained the reasons from my side, and it is up to WG's decision.
</fei>

For tunnel_num, the only confusion is the Z9-tunnel_num for co-routed 
bidirectional LSP which is introduced by RFC 6370, but IMHO, it’s 
unnecessary, especially when the LSP is signaled dynamically. If 
Z9-tunnel_num needed, does it mean Z9-LSP_num is also needed? In addition, 
did anyone find any issues when implement RFC3473?

 <fei>
LSP_num keeps the same value, please check section 5.2.1 of RFC6370. 

Sorry for the misunderstanding. The exchanges of MEP_ID can be based on 
control plane, data plane or management plane, and I do not think it will 
affect the
implementation of RFC3473, the reasons are just like that RFC4872 and 
RFC4873 will not affect the existence of RFC3473.
</fei>
 
As discussed with Lou several months ago on the same issue, the best way 
is to update( or an errata)  RFC6370 to clarify that : for co-routed 
bidirectional LSP, A1-tunnel_num is the same as Z9-tunnel_num. 
 
 <fei>
It is not necessarily the same...
</fei>

Best regards,
Mach
 
Subject: RE: [CCAMP] poll on making 

Best 

Fei 

收件人

Hi Fei,

<fei> 

<fei> 

<fei> 

</fei>

<fei> 
See above 
</fei>

<fei> 

</fei> 
Best regards,
Mach

---

From: John E Drake <[email-masked]>
Date: Thu, 24 May 2012 05:59:06 -0700

Lou,

I don't understand the problem being solved by this draft.

For a co-routed bi-directional LSP, there is a common 5 tuple.  For an associated bi-directional LSP, there is a separate 5 tuple for each uni-directional LSP, but they are coupled using the procedures defined in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03, by the same author.

The mapping of the 5 tuple into MEP IDs is described in:  http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext

Thanks,

John

Sent from my iPhone

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Lou Berger
>Sent: Monday, May 21, 2012 5:47 AM
>To: [email-masked]
>Subject: [CCAMP] poll on making draft-zhang-ccamp-mpls-tp-rsvpte-ext-
>tunnel-num-02 a WG document
>
>All,
>
>draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 a ccamp working group
>document. Please send mail to the list indicating "yes/support"

---

From: Lou Berger <[email-masked]>
Date: Thu, 24 May 2012 10:50:47 -0400

John,
	The problem that I'm aware of that relates to this draft is how an
ingress (MEG) can learn the RFC6370 defined Z9-Tunnel_Num for a
*corouted* bidirectional LSPs.  Take a look at RFC6370 Section 5.3 and
you'll see this point is not addressed.  I also don't see anything in
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext on this.

As chair, I'm not making any technical comment on how well this document
addresses this requirement, but asking if the WG wants to use this
individual draft as the basis of the WG solution to this problem.  Keep
in mind, that any individual document is just a starting point for the
WG and once it is a WG document it is the WG that directs changes and
documents contents.

As chair, I'm happy to see an open problem being addressed, and am open
to using this document as the foundation for the WG, or rolling the
function into the existing document (which would need to be rescoped to
cover co-routed as well as Associated bidirectional LSPs), as long as
we're following WG consensus.

Lou

On 5/24/2012 8:59 AM, John E Drake wrote:
> For a co-routed bi-directional LSP, there is a common 5 tuple.  For
> an associated bi-directional LSP, there is a separate 5 tuple for
> each uni-directional LSP, but they are coupled using the procedures
> defined in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03, by
> the same author.
> 
> The mapping of the 5 tuple into MEP IDs is described in:
> http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext
>
>  Thanks,
> 
> John
> 
> Sent from my iPhone
> 
>

---

From: John E Drake <[email-masked]>
Date: Thu, 24 May 2012 08:17:20 -0700

Comment inline

Sent from my iPhone

>From: Lou Berger [mailto:[email-masked]]
>Sent: Thursday, May 24, 2012 7:51 AM
>To: John E Drake
>Cc: [email-masked]
>Subject: Re: [CCAMP] poll on making draft-zhang-ccamp-mpls-tp-rsvpte-
>ext-tunnel-num-02 a WG document
>
>John,

JD:  What draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext states is the following:

<"Unique MEP-ID of source of BFD packet"> ::= <src_node_id><src_tunnel_num><lsp_num>

Note that support of ITU IDs is out-of-scope.

GMPLS signaling [RFC3473] uses a 5-tuple to uniquely identify an LSP within an operator's network.  This tuple is composed of      a Tunnel Endpoint Address, Tunnel_ID, Extended Tunnel ID, and Tunnel Sender Address and (GMPLS) LSP_ID.

Hence, the following mapping is used without the need of redefining a new TLV for MPLS-TP proactive CV purpose.

      - Tunnel ID = src_tunnel_num

      - Tunnel Sender Address = src_node_id

      - LSP ID = LSP_Num

"Tunnel ID" and "Tunnel Sender Address" are included in the "SESSION" object [RFC3209], which is mandatory in both Path and Resv messages.  "LSP ID" will be the same on both directions and it is included in the "SENDER_TEMPLATE" object [RFC3209] which is mandatory in Path messages.

---

From: Lou Berger <[email-masked]>
Date: Thu, 24 May 2012 13:19:52 -0400

John,
	How does an ingress get the egress' tunnel number in the corouted
bidirectional LSP case?  Per RFC6370:

   the format of an MPLS-TP co-routed bidirectional LSP_ID is:

      A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num

Lou

---

From: John E Drake <[email-masked]>
Date: Thu, 24 May 2012 10:35:38 -0700

Per the snippet I included in my previous email, it sounds as though it gets it from the Tunnel ID (= src_tunnel_num) and the Tunnel Sender Address (= src_node_id) in the SESSION object [RFC3209] in the Resv it receives.

Sent from my iPhone

>Sent: Thursday, May 24, 2012 10:20 AM
>To: John E Drake
>Cc: [email-masked]
>>> *corouted* bidirectional LSPs.  Take a look at RFC6370 Section 5.3
>>> and you'll see this point is not addressed.  I also don't see
>>> anything in draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext on this.
>>
>>
>> GMPLS signaling [RFC3473] uses a 5-tuple to uniquely identify an LSP
>within an operator's network.  This tuple is composed of      a Tunnel
>Endpoint Address, Tunnel_ID, Extended Tunnel ID, and Tunnel Sender
>Address and (GMPLS) LSP_ID.
>>
>> Hence, the following mapping is used without the need of redefining a
>new TLV for MPLS-TP proactive CV purpose.
>>
>> "Tunnel ID" and "Tunnel Sender Address" are included in the "SESSION"
>object [RFC3209], which is mandatory in both Path and Resv messages.
>"LSP ID" will be the same on both directions and it is included in the
>"SENDER_TEMPLATE" object [RFC3209] which is mandatory in Path messages.
>>
>>
>>
>>
>>

---

From: [email-masked]
Date: Fri, 25 May 2012 14:14:47 +0800

Hi John

I am not sure I catch your idea correctly

Actually, Adrian also said that "... Of course, RFC 3209 has some quite 
good mechanisms for that :-)" in the previous mail

Do you mean Z9-tunnel_num is filled in the SESSION object in the Resv 
message? 

If it is the proposed solution, the SESSION1 object (Path message) is 
changed to the SESSION2 object (Resv message), how the ingress and 
intermediated nodes find that the SESSION2 object is actually associated 
with the SESSION1 object, then updating the PSB and creating RSB? 

Or do I have any misunderstading?

Hope you can shed some light on me

Best regards

Fei

John E Drake <[email-masked]> 
发件人:  [email-masked]
2012-05-25 01:35

收件人
Lou Berger <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [CCAMP] poll on     making 
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 a    WG document

Per the snippet I included in my previous email, it sounds as though it 
gets it from the Tunnel ID (= src_tunnel_num) and the Tunnel Sender 
Address (= src_node_id) in the SESSION object [RFC3209] in the Resv it 
receives.

Sent from my iPhone

---

From: [email-masked]
Date: Fri, 25 May 2012 17:01:48 +0800

Hi John

According to RFC6428, section 3.5.2

The LSP MEP_ID TLV is as follow:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type                         |  Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       MPLS-TP Global_ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    MPLS-TP Node Identifier                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tunnel_Num          |            LSP_Num            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And my understanding is that the Global_ID is not covered by the draft 
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext:

<"Unique MEP-ID of source of BFD packet"> ::= 
<src_node_id><src_tunnel_num><lsp_num>

Best regards

Fei

2012-05-24 23:17

收件人

Comment inline

Sent from my iPhone

>draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext on this.

JD:  What draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext states is the 
following:

<"Unique MEP-ID of source of BFD packet"> ::= 
<src_node_id><src_tunnel_num><lsp_num>

GMPLS signaling [RFC3473] uses a 5-tuple to uniquely identify an LSP 
within an operator's network.  This tuple is composed of      a Tunnel 
Endpoint Address, Tunnel_ID, Extended Tunnel ID, and Tunnel Sender Address 
and (GMPLS) LSP_ID.

Hence, the following mapping is used without the need of redefining a new 
TLV for MPLS-TP proactive CV purpose.

      - LSP ID = LSP_Num

"Tunnel ID" and "Tunnel Sender Address" are included in the "SESSION" 
object [RFC3209], which is mandatory in both Path and Resv messages.  "LSP 
ID" will be the same on both directions and it is included in the 
"SENDER_TEMPLATE" object [RFC3209] which is mandatory in Path messages.

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 May 2012 08:22:26 -0400

John,

The session object in the resv is the same as is in the path.  Changing
this would be a change to 2205 and not a good idea.

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 May 2012 08:48:20 -0400

John/Fei,

I think the following text from 6428 that proceeds the object definition
may be helpful:

   3.5.2.  LSP MEP-ID

   The fields for the LSP MEP-ID are as defined in [9].  This is
   applicable to both LSPs and SPMEs.  This consists of the 32-bit MPLS-
   TP Global_ID, the 32-bit Node Identifier, followed by the 16-bit
   Tunnel_Num (that MUST be unique within the context of the Node
   Identifier), and the 16-bit LSP_NUM (that MUST be unique within the
   context of the Tunnel_Num).  The format of the TLV is:

6428 assumes each end of a birdirectional LSP have the other end's
MEP-ID to support CV:
   The CV PDUs
   are augmented with a Source MEP-ID TLV to permit mis-connectivity
   detection to be performed by sink MEPs.

Lou

On 5/25/2012 5:01 AM, [email-masked] wrote:
> *John E Drake <[email-masked]>*

---

From: John E Drake <[email-masked]>
Date: Fri, 25 May 2012 07:23:31 -0700

Lou,

As I indicated in my email, that was my reading of draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext.  I think my reading was correct, but as you point out, that is not the way things work.  So, once we figure out the correct answer, this draft will need to be updated.

I will be sending another email with some suggestions.

Thanks,

John  

Sent from my iPhone

>Sent: Friday, May 25, 2012 5:22 AM
>To: John E Drake
>Cc: [email-masked]
>> Per the snippet I included in my previous email, it sounds as though
>it gets it from the Tunnel ID (= src_tunnel_num) and the Tunnel Sender
>>> "LSP ID" will be the same on both directions and it is included in
>>> the "SENDER_TEMPLATE" object [RFC3209] which is mandatory in Path
>messages.
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 May 2012 10:47:59 -0400

It was my understanding that draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext
matched RFC 6428, which has each end sending its own information and the
receiver validating the info based on configured/signaled information,
i.e., needing to know the remote end's MEP IDs.

Lou

---

From: John E Drake <[email-masked]>
Date: Fri, 25 May 2012 07:49:16 -0700

Lou,

Thanks for quoting my text, which I wrote based upon a version of RFC 6370 when it was still a draft.

Unfortunately, as published, RFC 6370 is not internally consistent with my text.  According to my text, we would have the following two MEP IDs: [A1 Node ID, A1 Tunnel_Num, A1 LSP ID (aka LSP_Num)],  [Z9 Node ID, Z9 Tunnel_Num, Z9 LSP ID].

Unfortunately, RFC 6370 doubles down on LSP-ID by saying that LSP ID is the same in both MEP IDs.  Because an LSP ID is unique only in the context of Node ID and Tunnel_Num, this is incorrect.

So, I think we have the following choices:

1)  Change RFC 6370 to stipulate that LSP ID is unique in the context of [A1 Node ID, A1 Tunnel_Num] *and* [Z9 Node ID, Z9 Tunnel_Num] and change draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext to be consistent with this.

2)  Change RFC 6370 to indicate that there is an A1 LSP ID and a Z9 LSP ID and change draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext to include a TLV in Resv that contains [Z9 Tunnel_Num, Z9 LSP ID]

3)  Change RFC 6370 to use the 5 tuple defined in RFC 3209, and change draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and RFC 6428 to be consistent with this.

My personal choice is 3) but any of them are acceptable.

Thanks,

John

Sent from my iPhone

>Sent: Friday, May 25, 2012 5:48 AM
>To: [email-masked]; John E Drake
>Cc: [email-masked]
>6428 assumes each end of a birdirectional LSP have the other end's MEP-
>ID to support CV:
>   The CV PDUs
>document

---

From: John E Drake <[email-masked]>
Date: Fri, 25 May 2012 07:57:39 -0700

The only text I saw was the text I included in my email at the bottom of this thread, which indicates that "Tunnel ID" and "Tunnel Sender Address" are extracted from the "SESSION" object [RFC3209].  In any event, the draft still has the issue with LSP ID that I just described in another email.

Sent from my iPhone

>Sent: Friday, May 25, 2012 7:48 AM
>To: John E Drake
>Cc: [email-masked]
>> As I indicated in my email, that was my reading of draft-ietf-ccamp-
>rsvp-te-mpls-tp-oam-ext.  I think my reading was correct, but as you
>point out, that is not the way things work.  So, once we figure out the
>correct answer, this draft will need to be updated.
>>
>>> The session object in the resv is the same as is in the path.
>>> Changing this would be a change to 2205 and not a good idea.
>>>
>>> Lou
>>>
>>> it gets it from the Tunnel ID (= src_tunnel_num) and the Tunnel
>>> Sender Address (= src_node_id) in the SESSION object [RFC3209] in the
>>> Resv it receives.
>>>>
>>>> Sent from my iPhone
>>>>
>>>>
>>>>>>> 	The problem that I'm aware of that relates to this draft is
>how
>>>>>>> an ingress (MEG) can learn the RFC6370 defined Z9-Tunnel_Num for
>>>>>>> a
>>>>>>> *corouted* bidirectional LSPs.  Take a look at RFC6370 Section
>>>>>>> 5.3 and you'll see this point is not addressed.  I also don't see

---

From: John E Drake <[email-masked]>
Date: Fri, 25 May 2012 08:12:04 -0700

Fei,

Per my other emails, I think it makes sense to update  draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext to allow the LSP endpoints to exchange whatever fields, including Global ID, Tunnel_Num, and LSP ID, we think are needed.

Thanks,

John

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 25, 2012 2:02 AM
To: John E Drake
Cc: [email-masked]; [email-masked]; Lou Berger
Subject: Re: [CCAMP] poll on making draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 a WG document

Hi John

    0                   1                   2                   3

And my understanding is that the Global_ID is not covered by the draft draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext:

Best regards

Fei

John E Drake <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2012-05-24 23:17

收件人

Lou Berger <[email-masked]<mailto:[email-masked]>>

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

Re: [CCAMP] poll on        making        draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 a        WG document

Comment inline

Sent from my iPhone

>Cc: [email-masked]<mailto:[email-masked]>

     - LSP ID = LSP_Num

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 May 2012 11:41:49 -0400

John,
	I'm have a little trouble following you, are you perhaps referencing
6370 rather than 6428 in a few places?  See specifics below.

On 5/25/2012 10:49 AM, John E Drake wrote:
> Lou,
> 
> Thanks for quoting my text, 

from 6428, right?

> which I wrote based upon a version of RFC
> 6370 when it was still a draft.
> 
> Unfortunately, as published, RFC 6370 is not internally consistent
> with my text.  

Your text as published?  If yes, it is entirely consistent.  If not, I
can't comment on your original text.

> According to my text, we would have the following two
> MEP IDs: [A1 Node ID, A1 Tunnel_Num, A1 LSP ID (aka LSP_Num)],  [Z9
> Node ID, Z9 Tunnel_Num, Z9 LSP ID].

This certainly makes sense for associated bidirectional, and this is in
section 5.2.2 of 6370 and is allowed for in 6428.

> 
> Unfortunately, RFC 6370 doubles down on LSP-ID by saying that LSP ID
> is the same in both MEP IDs.  

Only in the context of  Co-Routed Bidirectional, see section 5.2.1.

> Because an LSP ID is unique only in the
> context of Node ID and Tunnel_Num, this is incorrect.

I'm not sure if you referring to 6370 MPLS-TP LSP Identifier or RFC3209
LSP_ID in the context of 6428.  If the former, I'm not sure what your
are referring to.  If that latter, I agree the text "the 16-bit LSP_NUM
(that MUST be unique within the context of the Tunnel_Num)" may mislead
one to believe that the LSP_ID may not be unique across all tunnels, but
this would be incorrect as 3209 scopes LSP_ID to be unique per sender
and *not* per tunnel.  But I'm not sure that this text precludes this.

Are you referring to something else?

> So, I think we have the following choices:

Is this proposal for both co-router and associated bidirectional?

> 
> 1)  Change RFC 6370 to stipulate that LSP ID is unique in the context
> of [A1 Node ID, A1 Tunnel_Num] *and* [Z9 Node ID, Z9 Tunnel_Num] 

I don't think this is correct. 3209 allows the same LSP_ID to be used on
multiple tunnels.

> and
> change draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext to be consistent with
> this.
> 
> 2)  Change RFC 6370 to indicate that there is an A1 LSP ID and a Z9
> LSP ID 

6370 already does 2 for associated. The A1 and Z9 LSP_ID is *always*
identical for corouted associated.

> and change draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext to include
> a TLV in Resv that contains [Z9 Tunnel_Num, Z9 LSP ID]
> 

associated bidirection support is already covered in
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp (via association).

> 3)  Change RFC 6370 to use the 5 tuple defined in RFC 3209, and
> change draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and RFC 6428 to be
> consistent with this.

I can see this work for corouted, but how would it work for associated?

Lou

---

From: John E Drake <[email-masked]>
Date: Fri, 25 May 2012 09:20:08 -0700

Sent from my iPhone

>Sent: Friday, May 25, 2012 8:42 AM
>To: John E Drake
>Cc: [email-masked]; [email-masked]

JD:  Your email explicitly referenced text from 6428, so why is there a question?

>can't comment on your original text.

JD:  What part of "Unfortunately, as published, RFC 6370 is not internally consistent with my text."  do you not understand?

>Only in the context of  Co-Routed Bidirectional, see section 5.2.1.

JD:  Precisely

>
>> Because an LSP ID is unique only in the context of Node ID and
>> Tunnel_Num, this is incorrect.
>
>one to believe that the LSP_ID may not be unique across all tunnels,

JD:  From RFC 6370 section 5.2.1 (Co-Routed Bi-Directional LSPs):

"A co-routed bidirectional LSP can be uniquely identified by a single LSP number within the scope of an MPLS-TP Tunnel_ID.  Specifically, an LSP Number (LSP_Num) is a 16-bit unsigned integer unique within the Tunnel_ID."  

>but

JD:  I don't find any text in RFC 3209 that defines LSP_IP scope.

>I don't think this is correct. 3209 allows the same LSP_ID to be used on

JD:  As I indicated above, RFC 3209 is remarkably silent on the characteristics of LSP_IP.  But I think you missed my point, which is that the same LSP_ID must be unique within two different contexts, one on A1 and one on Z9.

>identical for corouted associated.

JD:  And that is the issue.  The LSP_ID is defined in the context of [A1 Node ID, A1 Tunnel_Num], but these two fields do not appear in a MEP ID for Z9.

---

From: John E Drake <[email-masked]>
Date: Fri, 25 May 2012 09:26:53 -0700

Snipped...

Sent from my iPhone

>
>> 3)  Change RFC 6370 to use the 5 tuple defined in RFC 3209, and change
>> draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and RFC 6428 to be consistent
>> with this.
>

JD:  There would be a different 5 tuple for each direction.

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 May 2012 12:44:15 -0400

> JD:  Your email explicitly referenced text from 6428, so why is there a question?

yes, but your mail only listed your text in 6370 so while I'm sure you
knew exactly what you meant, I don't.

> JD:  What part of "Unfortunately, as published, RFC 6370 is not
> internally consistent with my text."  do you not understand?
> 

Hereto, I'm sure you know what "my text" refers to, but I don't.

> "A co-routed bidirectional LSP can be uniquely identified by a single LSP number within the scope of an MPLS-TP Tunnel_ID.  Specifically, an LSP Number (LSP_Num) is a 16-bit unsigned integer unique…

" MPLS-TP Tunnel_ID" = A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}

the LSP_num is unique "within the scope of an MPLS-TP Tunnel_ID" (but
not necessarily across all MPLS-TP Tunnel_IDs.)

So what's the issue?

> JD:  I don't find any text in RFC 3209 that defines LSP_IP scope.

I think the object and its usage does:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 tunnel sender address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MUST be zero                 |            LSP ID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> JD:  As I indicated above, RFC 3209 is remarkably silent on the
> characteristics of LSP_IP.  But I think you missed my point, 

no doubt, I did day I was having trouble following you.

> which is
> that the same LSP_ID must be unique within two different contexts,
> one on A1 and one on Z9.

for associated bidirectional, I agree and this was been the case since
3209 was defined.  For co-routed, by implication, 3473 only defines lsp
id in the context of the ingress as it doesn't change the definition of
sender template.

I accept that 6428 is placing additional restrictions on scope of (RSVP)
LSP ID.  I thought that was part of the point the text that I previously
quoted.

> JD: And that is the issue. The LSP_ID is defined in the context of
> [A1 Node ID, A1 Tunnel_Num], but these two fields do not appear in a
> MEP ID for Z9.
> 

sure, and Z9 can choose its tunnel number to ensure that the A1 defined
LSP ID is unique within [Z1 Node ID, Z1 Tunnel_Num].  At least that's
one implication of the text in 6428 as published.

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 May 2012 12:45:58 -0400

Okay, that would work but both 6370 and 6428 would need to be updated to
consistent.

---

From: [email-masked]
Date: Sat, 26 May 2012 09:29:47 +0800

Lou/John

Another option fo discussion: keeping RFC6370 and RFC6428 untouched.

Since the LSP's identifiers have been specified in the ASSOCIATION object 
(draft-ietf-ccamp-assoc-ext-03.txt), a new association type can be defined 
(as the draft
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 suggested). The benifit 
is that the scheme for associated and corouted bidirectional LSPs utilizes 
the same extension, which also
allows for future potential applications (not only limited to CV function 
needed configuration).

Of course, the content can be integrated into the draft 
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext (citing the draft 
draft-ietf-ccamp-assoc-ext-03.txt, and defining the new
association type ) or into the draft draft-ietf-ccamp-assoc-ext-03.txt (a 
new association type is needed) or be kept seperated (like 
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02, but the descriptions 
in section 3.2 of the draft draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext need 
to be updated).

Anyway, be glad that we may have the consensus that the exchange of the 
MEP_ID is needed.

Best regards

Fei

2012-05-26 00:45

收件人
John E Drake <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [CCAMP] poll on making 
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 a WG document

---

From: John E Drake <[email-masked]>
Date: Sat, 26 May 2012 05:52:45 -0700

Lou,

It's what should have been done in the first place, but now it's probably too big a change. 

If we stipulate in RFC 6370 that for a co-routed bi-directional LSP the Z9 Tunnel_Num MUST equal the A1 Tunnel_Num AND the Z9 LSP ID MUST equal the A1 LSP ID then:

RFC 6428 is correct

draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext is correct

draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02 is not needed

It's very close to using the 5 tuple

Thanks,

John

Sent from my iPhone

>Sent: Friday, May 25, 2012 9:46 AM
>To: John E Drake

---

From: Lou Berger <[email-masked]>
Date: Sat, 26 May 2012 10:47:14 -0400

John,
	I'm all for simplification, but what happens when the Z9 already has an
LSP (that it or some other ingress originated) with the A1 tunnel number?

Lou

---

From: John E Drake <[email-masked]>
Date: Tue, 29 May 2012 06:06:55 -0700

Lou,

Oopsie.

Given that we have always used the 5 tuple to identify an LSP, does it really make sense to invent a new method to identify an LSP (Z9 Tunnel_Num) especially when we also need to invent a mechanism for the LSP ingress to learn it?

CV is intended to be performed by the slow path in software, meaning it is amenable to change.  Would it make sense to poll the MPLS and CCAMP mailing lists to see whether there is support for changing RFCs 6370 and 6428 to use the 5 tuple?

Thanks,

John 

Sent from my iPhone

>Sent: Saturday, May 26, 2012 7:47 AM
>To: John E Drake
>	I'm all for simplification, but what happens when the Z9 already
>has an LSP (that it or some other ingress originated) with the A1 tunnel
>number?
>
>Lou
>
>> If we stipulate in RFC 6370 that for a co-routed bi-directional LSP
>the Z9 Tunnel_Num MUST equal the A1 Tunnel_Num AND the Z9 LSP ID MUST
>equal the A1 LSP ID then:
>>
>> RFC 6428 is correct
>>
>>> Okay, that would work but both 6370 and 6428 would need to be updated
>>> to consistent.
>>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 May 2012 09:46:27 -0400

John,
	
	see below.

On 5/29/2012 9:06 AM, John E Drake wrote:
> Lou,
> 
> Oopsie.
> 
> Given that we have always used the 5 tuple to identify an LSP, does
> it really make sense to invent a new method to identify an LSP (Z9
> Tunnel_Num) 

I believe the intent was to maximize consistency between associated and
corouted bidirectional TP LSPs.  That said, this is really a discussion
for the authors of 6370 and the MPLS WG.

> especially when we also need to invent a mechanism for
> the LSP ingress to learn it?

I personally (chair hat off) don't see communicating this as a big deal.
 There are lots of possible mechanisms we can leverage (the draft being
polled suggests one.)  To me it's a question of where the complexity
lives; in this case, in OAM or in the CP.  As I see it (again no hat)
6370 simplifies OAM at the cost of added CP complexity -- which I'm
personally okay with, but I also didn't feel strongly about this at the
time it was being discussed in the MPLS WG.  I'm pretty sure, but can't
remember for sure, bringing this point up during one of George's
presentations.

> 
> CV is intended to be performed by the slow path in software, meaning
> it is amenable to change.  Would it make sense to poll the MPLS and
> CCAMP mailing lists to see whether there is support for changing RFCs
> 6370 and 6428 to use the 5 tuple?

I suspect changing TP OAM at this point would be a *big deal*.  I'm
cc'ing the MPLS-WG chairs on the off chance they want to chime in.

Lou

---

From: John E Drake <[email-masked]>
Date: Tue, 29 May 2012 07:18:17 -0700

Lou,

The OAM complexity is the same, checking some fields in a received CV message against expected values.  So, we are adding control plane complexity and inconsistency with the 5 tuple for no advantage.

Thanks,

John 

Sent from my iPhone

>Sent: Tuesday, May 29, 2012 6:46 AM
>To: John E Drake
>Cc: [email-masked]; [email-masked]; Adrian Farrel; mpls-
>[email-masked]
>> Given that we have always used the 5 tuple to identify an LSP, does it
>> really make sense to invent a new method to identify an LSP (Z9
>> Tunnel_Num)
>
>> especially when we also need to invent a mechanism for the LSP ingress
>> to learn it?
>
>has
>>> an LSP (that it or some other ingress originated) with the A1 tunnel
>>> number?
>>>
>>> Lou
>>>
>>>>> Okay, that would work but both 6370 and 6428 would need to be
>>>>> updated to consistent.
>>>>>
>>>>>>>> change draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and RFC 6428 to
>>>>>>>> be consistent with this.
>>>>>>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 May 2012 10:34:14 -0400

John,
	I think the issue with changing CV at this point is more procedural
than technical.  Either way, making that call/change is up to the MPLS WG.

>From the CCAMP perspective, my feeling (chair hat on) is that the WG
should continue doing work based on the existing RFCs and change
direction if/when MPLS WG reaches consensus on doing a (or multiple) bis
on the RFC.

In other words, I think we should continue the poll assuming that the
requirements implied by RFCs 6370 and 6428 are correct, and that
z9-Tunnel number does need to be communicated to the ingress in the
co-routed bidirectional case.

We can always shelve the resulting CCAMP WG document if the MPLS WG
adopts 6370-bis/6428-bis drafts as MPLS WG documents.

Lou

On 5/29/2012 10:18 AM, John E Drake wrote:
> Lou,
> 
> The OAM complexity is the same, checking some fields in a received CV
> message against expected values.  So, we are adding control plane
> complexity and inconsistency with the 5 tuple for no advantage.
> 
> Thanks,
> 
> John 
> 
> Sent from my iPhone
> 
>

---

From: John E Drake <[email-masked]>
Date: Tue, 29 May 2012 07:42:27 -0700

Lou,

That's fine.

My preference is that the mechanism for communicating the Z9 Tunnel_Num to the ingress be documented in draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext rather than in the subject draft, because draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext already deals with the topic of control plane initialization of OAM and it doesn't seem sensible to have a integral part of that initialization be documented in another draft.

Thanks,

John

Sent from my iPhone

>Sent: Tuesday, May 29, 2012 7:34 AM
>To: John E Drake
>	I think the issue with changing CV at this point is more
>procedural than technical.  Either way, making that call/change is up to
>the MPLS WG.
>
>requirements implied by RFCs 6370 and 6428 are correct, and that z9-
>Tunnel number does need to be communicated to the ingress in the co-
>routed bidirectional case.
>
>>> I believe the intent was to maximize consistency between associated
>>> and corouted bidirectional TP LSPs.  That said, this is really a
>>> discussion for the authors of 6370 and the MPLS WG.
>>>
>>>> especially when we also need to invent a mechanism for the LSP
>>>> ingress to learn it?
>>>
>>> There are lots of possible mechanisms we can leverage (the draft
>>> being polled suggests one.)  To me it's a question of where the
>>> complexity lives; in this case, in OAM or in the CP.  As I see it
>>> (again no hat)
>>> personally okay with, but I also didn't feel strongly about this at
>>> the time it was being discussed in the MPLS WG.  I'm pretty sure, but
>>> can't remember for sure, bringing this point up during one of
>>> George's presentations.
>>>
>>>>
>>>>> an LSP (that it or some other ingress originated) with the A1
>>>>> tunnel number?
>>>>>
>>>>> Lou
>>>>>
>>>>> the Z9 Tunnel_Num MUST equal the A1 Tunnel_Num AND the Z9 LSP ID
>>>>> MUST equal the A1 LSP ID then:
>>>>>>
>>>>>> RFC 6428 is correct
>>>>>>
>>>>>>>>>> 3)  Change RFC 6370 to use the 5 tuple defined in RFC 3209,
>>>>>>>>>> and change draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext and RFC
>>>>>>>>>> 6428 to be consistent with this.
>>>>>>>>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 May 2012 11:16:33 -0400

John,
	From a technical stand point, I don't really see the difference between
1 document or 2, as the mechanisms differ and to a large degree can be
implemented independently, and would be happy with either.

>From a process standpoint, I'm inclined to keep them separate for the
simple reason that draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext is very
mature (about to be last called) while the tunnel draft is just now
entering the formal WG (consensus) process.

That said, I'd like to hear from others in the WG, particularly other
contributors to rsvp-te-mpls-tp-oam-ext, about their thoughts on adding
this mechanism to rsvp-te-mpls-tp-oam-ext.  If there's general support
from the WG to delay that draft, we should consider it.

Lou

On 5/29/2012 10:42 AM, John E Drake wrote:
> Lou,
> 
> That's fine.
> 
> My preference is that the mechanism for communicating the Z9
> Tunnel_Num to the ingress be documented in
> draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext rather than in the subject
> draft, because draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext already deals
> with the topic of control plane initialization of OAM and it doesn't
> seem sensible to have a integral part of that initialization be
> documented in another draft.
> 
> Thanks,
> 
> John
> 
> Sent from my iPhone
> 
>