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

[David Ball <[e-mail]>]

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:[e-mail]]
> > >>Sent: 12 December 2012 17:45
> > >>To: [e-mail]; [e-mail]; [e-mail];
> > >>[e-mail]; [e-mail];
> > >>[e-mail]; [e-mail]; [e-mail]; [e-mail];
> > >>[e-mail]
> > >>Cc: [e-mail]; [e-mail]; [e-mail]
> > >>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 <[e-mail]>
> > >>
> > >>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
> > >[e-mail]
> > >https://www.ietf.org/mailman/listinfo/mpls
> > >
> > 
> > 
> > -- 
> > Yoshinori Koike
> > [e-mail]
> > 
> 
> -- 
> David Ball
> <[e-mail]>

-- 
David Ball
<[e-mail]>