Subject: [mpls] [Editorial Errata Reported] RFC6435 (3429)

From: RFC Errata System <[email-masked]>
Date: Wed, 12 Dec 2012 09:44:31 -0800 (PST)

The following errata report has been submitted for RFC6435,
"MPLS Transport Profile Lock Instruct and Loopback Functions".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429

--------------------------------------
Type: Editorial
Reported by: David Ball <[email-masked]>

Section: 4 (para 5)

Original Text
-------------
It should be noted that the data-plane loopback function itself is applied to data-plane loopback points residing on different interfaces from MIPs/MEPs.

Corrected Text
--------------
It should be noted that the data-plane loopback function may be applied at MIPs/MEPs on different interfaces for different LSPs.

Notes
-----
The existing text has caused confusion (specifically, among experts in ITU-T SG15 when discussing G.8121.2), in that it seems to suggest that the interface where the MIP/MEP is located may be a different interface to the one where the loopback is applied.
Having spoken with some of the original authors, it seems this was not the intent of this sentence; the intent was to point out that as different LSPs would have MIPs/MEPs on different interfaces, the corresponding loopback functions would also be applied on different interfaces.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6435 (draft-ietf-mpls-tp-li-lb-08)
--------------------------------------
Title               : MPLS Transport Profile Lock Instruct and Loopback Functions
Publication Date    : November 2011
Author(s)           : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, Ed., X. Dai, Ed.
Category            : PROPOSED STANDARD
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Dec 2012 18:17:05 -0000

Hello,

Authors of RFC 6435: I need to hear from you that you meant the text that David
suggests. It is very clearly not what you wrote and, if you meant something
different, it is clear why people are confused!

Working group: I need to hear from you that you agree with David's
interpretation and support his proposed change.

Only then will I try to work out whether this is a "typo" worthy of an errata
report, or a technical change needing a revised RFC.

Thanks,
Adrian

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]]
> Sent: 12 December 2012 17:45
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Editorial Errata Reported] RFC6435 (3429)
> 
> 
> It should be noted that the data-plane loopback function itself is applied to
data-
> plane loopback points residing on different interfaces from MIPs/MEPs.
> 
> Corrected Text
> --------------
> It should be noted that the data-plane loopback function may be applied at
> MIPs/MEPs on different interfaces for different LSPs.
> 
> Notes
> -----
> The existing text has caused confusion (specifically, among experts in ITU-T
SG15
> when discussing G.8121.2), in that it seems to suggest that the interface
where
> the MIP/MEP is located may be a different interface to the one where the
> loopback is applied.
> 
> Having spoken with some of the original authors, it seems this was not the
intent
> of this sentence; the intent was to point out that as different LSPs would
have
> MIPs/MEPs on different interfaces, the corresponding loopback functions would
> also be applied on different interfaces.
> 
> Instructions:
> -------------
> Author(s)           : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M.
Vigoureux,
> Ed., X. Dai, Ed.

---

From: Yoshinori Koike <[email-masked]>
Date: Sat, 15 Dec 2012 02:42:32 +0900

Hello David,

I agree with original text is confusing and thank you for the proposal. 
However, I'm wondering if the proposed text is true and exactly reflect 
the intent explained in the notes.

My suggestion is as follows:
It should be noted that the data-plane loopback function itself is 
applied to data-plane loopback point which is different from MIP/MEP.

Firstly, the description "the data-plane loopback function may be 
applied at MIPs/MEPs" doesn't seem to be true.

In my understanding, data-plane loopback function can be 
set/enabled/disabled at MIP/MEP using a management system but not be 
applied to MIP/MEP itself. So I clarified this point in my proposal.

One of the reason is that MIP/MEP is only involved in OAM packets. There 
seems no specification in any RFC, which describe that MIP/MEP could 
handle data packets which are not OAM packets .

In G.8121 amd1, data-plane loopback sink and source are specified and 
according to Temporary Document(TD673R1<->R0/Plen) during last SG15 
meeting, the data-plane loopback sink/source was removed from figures of 
MTDe_TT_Sk/So Process(Fig.9-14&16). I guess this might be to avoid a 
restriction of implementations, however it doesn't seem to make it 
possible to apply dataplane loopback point to MIP/MEP. In realty, if 
data-plane loopback function is enabled, for data-plane LB function 
there is no need to parse the packet except for outermost label value.

Secondly, if you need to clarify the relationship between data-plane LB 
point at which data-plane LB function is conducted and MIP/MEP at which 
data-plane LB function is enabled/configured using management system, it 
seems enough just to say the two point usually resides on the same 
interface and clarify the binding of two points. I have no issue on this 
specification. However, just in case, it seems better to confirm if the 
change is ok in ITU-T joint interregnum meeting Jan 2013, because this 
is a matter of 8121 or/and G.8121.1. As a result, I didn't add related 
text in my proposal.

I'm not an implementer, so I would appreciate it if you could correct me 
if I'm wrong. Thank you in advance.

Best regards,

Yoshinori

(2012/12/13 3:17), Adrian Farrel wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 
Yoshinori Koike
[email-masked]

---

From: Yoshinori Koike <[email-masked]>
Date: Sat, 15 Dec 2012 03:40:38 +0900

Hello David,

Sorry, there was a mis-description in the previous email. Not G.8121.1 
but G.8121.2.

Best regards,

Yoshinori

(2012/12/15 2:42), Yoshinori Koike wrote:
>>> applied to

---

From: David Ball <[email-masked]>
Date: Mon, 17 Dec 2012 14:05:41 +0000

Hi Yoshinori,

Thanks for your comments.

With regards to your proposal, I am still a little unclear on the 
intended relationship between the dataplane loopback point and the 
MIP/MEP.  Are these always on the same interface?  If not, under what 
conditions could they be on different interfaces?  How is the location 
of the dataplane loopback point determined?

To take a concrete example, suppose we have an interface with both a LSP 
MEP and a PW MEP.  OAM packets destined for the LSP MEP will have an LSP 
label and a GAL, while OAM packets destined for the PW MEP will have an 
LSP label and a PW label.  Client data traffic will also have both an 
LSP and a PW label.

Now, if either the LSP MEP or the PW MEP are put into a loopback mode, 
all of the client data packets will be looped.  But which OAM packets 
are looped?
 - If the LSP MEP is put into loopback mode, do the LSP OAM packets get 
   looped?  I think so, since RFC6435 says that both data and OAM 
   packets are looped.
 - If the LSP MEP is put into loopback mode, do the PW OAM packets get 
   looped?  Again, I think so.
 - If the PW MEP is put into loopback mode, do the PW OAM packets get 
   looped?  I think yes, this is equivalent to the first case.
 - If the PW MEP is put into loopback mode, do the LSP OAM packets get 
   looped.  Since they do not have a PW label, I am not sure?  I think 
   probably they shouldn't be, since there may be other PWs flowing over 
   the same LSP, with different PW labels, right?

Regarding ITU-T G.8121 Amd 1 and G.8121.2, the reason the dataplane 
loopback process was removed from the MTDe figures in the last SG15 
meeting was because of this confusing sentence in RFC6435 - in other 
words, it wasn't clear whether the MTDe function was the right place for 
them so as to match the behaviour specified in the RFC.  The intent of 
G.8121.2 is to exactly match RFC6435 and the other relevant IETF RFCs.

As a result, in the current ITU-T G.8121/G.8121.2, the dataplane 
loopback processes do not appear in any of the termination or adaptation 
functions that are specified; so although the processes themselves are 
defined, they are never applied.  The question is, what is the correct 
place to apply them in the ITU-T model so as to match the RFC?

	David

On Sat, Dec 15, 2012, Yoshinori Koike wrote:
> Hello David,
> 
> I agree with original text is confusing and thank you for the
> proposal. However, I'm wondering if the proposed text is true and
> exactly reflect the intent explained in the notes.
> 
> One of the reason is that MIP/MEP is only involved in OAM packets.
> There seems no specification in any RFC, which describe that MIP/MEP
> could handle data packets which are not OAM packets .
> 
> In G.8121 amd1, data-plane loopback sink and source are specified
> and according to Temporary Document(TD673R1<->R0/Plen) during last
> SG15 meeting, the data-plane loopback sink/source was removed from
> figures of MTDe_TT_Sk/So Process(Fig.9-14&16). I guess this might be
> to avoid a restriction of implementations, however it doesn't seem
> to make it possible to apply dataplane loopback point to MIP/MEP. In
> realty, if data-plane loopback function is enabled, for data-plane
> LB function there is no need to parse the packet except for
> outermost label value.
> 
> Secondly, if you need to clarify the relationship between data-plane
> LB point at which data-plane LB function is conducted and MIP/MEP at
> which data-plane LB function is enabled/configured using management
> system, it seems enough just to say the two point usually resides on
> the same interface and clarify the binding of two points. I have no
> issue on this specification. However, just in case, it seems better
> to confirm if the change is ok in ITU-T joint interregnum meeting
> Jan 2013, because this is a matter of 8121 or/and G.8121.1. As a
> result, I didn't add related text in my proposal.
> 
> I'm not an implementer, so I would appreciate it if you could
> correct me if I'm wrong. Thank you in advance.
> 
> Best regards,
> 
> Yoshinori
> 
> 

-- 
David Ball
<[email-masked]>

---

From: Yuji Tochio <[email-masked]>
Date: Wed, 19 Dec 2012 08:50:13 +0900

Hi Adrian and all.

I am OK for David Ball's proposal, since it states more clearly about
loopback fucntions, given that his report from authors is correct.

Thanks,
Yuji (,as one of those discussing G.8121.2 and its editor)