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

[Yoshinori Koike <[e-mail]>]

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:
> 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]