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

From: David Ball <[email-masked]>
Date: Fri, 4 Jan 2013 11:00:33 +0000

Hi Yoshinori,

Did you have any further thoughts on this?

Thanks,

	David

On Mon, Dec 17, 2012, David Ball wrote:
> 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.
> > 
> > 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:
> > >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)
> > >>
> > >>
> > >>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
> > >
> > >_______________________________________________
> > >mpls mailing list
> > >[email-masked]
> > >https://www.ietf.org/mailman/listinfo/mpls
> > >
> > 
> > 
> > -- 
> > Yoshinori Koike
> > [email-masked]
> > 
> 
> -- 
> David Ball
> <[email-masked]>

-- 
David Ball
<[email-masked]>

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 9 Jan 2013 15:18:28 +0100

Adrian, David,

what I think we meant here was that a loop-back function could be done 
on an interface regardless of the presence of a MIP/MEP on that 
interface. Yet, I have to admit that MIP and MEP are used in Section 4 
of RFC6435, thus surely causing confusion.

I'd welcome the views/souvenirs of my co-authors.

-m

Le 12/12/2012 19:17, Adrian Farrel a écrit :
>> Reported by: David Ball<[email-masked]>
>>
>> Section: 4 (para 5)
>>
>> Original Text
>> -------------

---

From: "Sami Boutros (sboutros)" <[email-masked]>
Date: Wed, 9 Jan 2013 17:59:02 +0000

I agree with Martin, the text proposed by David describe more accurately what we meant.

Thanks,

Sami
On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote:

> Adrian, David,
> 
> what I think we meant here was that a loop-back function could be done on an interface regardless of the presence of a MIP/MEP on that interface. Yet, I have to admit that MIP and MEP are used in Section 4 of RFC6435, thus surely causing confusion.
>

---

From: Yoshinori Koike <[email-masked]>
Date: Thu, 10 Jan 2013 15:19:42 +0900

Hi David,

I'm terribly sorry for the delay in replying to you. Thank you very much 
for the reply. See in line, please.

>> of the dataplane loopback point determined?

I think it depends on the maintenance model. In per-node model, it will 
be impossible when MIP/MEP is placed on forwarding engine. However, I've 
heard that in most of the implementation of routers, MIP/MEP is placed 
on ingress-IF. Then there seems no issue that both MIP/MEP and 
data-plane loopback point are located on the same ingress-IF. In 
per-interface model, I think these are usually on the same interface, 
although some implementation may/might implement on only one side of 
interfaces(only ingress-IF).

It seems ideal that data-plane loopback point is located before MIP/MEP 
on ingress IF and/or after MIP/MEP on egress IF.

>> LSP label and a PW label.  Client data traffic will also have both an

Correct me if I'm wrong, but I guess you assume that both a LSP MEP and 
a PW MEP are placed on the same ingress-IF in a per-node model, which is 
said to be the most typical model of IP/MPLS routers.

>>     the same LSP, with different PW labels, right?

My assumption was that if a data-plane loopback function is enabled 
using the LSP MEP, a data-plane loopback point(s) (in my understanding, 
a data-plane loopback sink and source process) in ingress-IF is enabled, 
all the traffics that the data-plane loopback sink process has received 
get looped through data-plane source process.

Although the position of data-plane loopback process is located is not 
detailed in G.8121 including G.8121 amd1 under AAP, it doesn't seem to 
be considered only OAM packets get looped at the loopback process. In 
addition, when a data-plane loopback function is enabled, I think OAM 
functions should be disabled in principle.

>> place to apply them in the ITU-T model so as to match the RFC?

Thank you for the clarification. My understanding of G.8121 amd is that 
a data-plane loopback point is located before MIP/MEP on ingress IF 
and/or after MIP/MEP on egress IF and whether the type of data is 
AI/CI/client depends on the implementation.

Best regards,

Yoshinori

---

From: Yoshinori Koike <[email-masked]>
Date: Thu, 10 Jan 2013 21:16:05 +0900

Hi David,

Sorry, there was mis-description.

My understanding of G.8121 amd is that a position of data-plan loopback 
process is not restricted, as I wrote in my email on Dec 15, 2012.

Best regards,

Yoshinori

(2013/01/10 15:19), Yoshinori Koike wrote:
>>>>>> applied to

---

From: David Ball <[email-masked]>
Date: Thu, 10 Jan 2013 17:55:44 +0000

Hi Yoshinori,

Currently in G.8121 amd 1, the dataplane loopback function is not 
present in any atomic functions at all; ie, it cannot be instantiated.

	David

On Thu, Jan 10, 2013, Yoshinori Koike wrote:
> My understanding of G.8121 amd is that a position of data-plan
> loopback process is not restricted, as I wrote in my email on Dec
> 15, 2012.
> 
> Best regards,
> 
> Yoshinori
> 

-- 
David Ball
<[email-masked]>