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

[David Ball <[e-mail]>]

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:
> 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:
> >Hi David,
> >
> >I'm terribly sorry for the delay in replying to you. Thank you very much
> >for the reply. See in line, please.
> >
> >(2013/01/04 20:00), David Ball wrote:
> >>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?
> >
> >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.
> >
> >>>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.
> >
> >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.
> >
> >>>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?
> >
> >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.
> >
> >>>
> >>>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?
> >
> >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
> >
> >>>
> >>>
> >>>    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]>
> >>
> >
> >
> 
> 
> -- 
> Yoshinori Koike
> [e-mail]
> 

-- 
David Ball
<[e-mail]>