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

["Sami Boutros (sboutros)" <[e-mail]>]

On Jan 17, 2013, at 4:57 AM, Martin Vigoureux wrote:

> Adrian, yes, we are.
> 
> So, David,
> 
> I am fine with your suggested text which says:
>   It should be noted that the data-plane loopback function for a
>   given transport path can be applied to data-plane loopback points
>   residing on interfaces where there may be no corresponding MEP or
>   MIP.
> 
> I was thinking of:
> s/may be no corresponding MEP or MIP./may be no MEP or MIP for that transport path./
> but this is optional.
> 

Sami: I think this is more clear to add "for that transport path"

> The new text will replace:
>   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.
> 
> 
> Regarding the other paragraphs:
>   The loopback function is used to test the integrity of a transport
>   path from a MEP up any other node in the same MEG.  This is achieved
>   by setting the target node into loopback mode, and transmitting a
>   pattern of test data from the MEP.  The target node loops all
>   received data back toward the originator, and the MEP extracts the
>   test data and compares it with what it sent.
> 
>   Loopback is a function that enables a receiving MEP or MIP to return
>   traffic to the sending MEP when in the loopback state.
> 
>   [...]
> 
>   The management plane must ensure that the two MEPs are locked before
>   it requests setting MEP or MIP in the loopback state.
> 
> 
> They could be changed into:
>   The loopback function is used to test the integrity of a transport
>   path.  This is achieved by setting a given node into loopback mode

>   for a given transport path,

Sami: 
I would change
"a given node into loopback mode for a given transport path"
to 
"a given node on the transport path in loopback mode"
Sami: 

> and sending over it a pattern of test
>   data.  The node in loopback mode loops all test data received on the
>   transport path back towards the sender, which extracts the test
>   data and compares it with what it sent.
> 
>   Loopback is a function which enables a given node of a transport

Sami: 

I would change 
"given node of a transport path"
to
"given node on a transport path"

Sami
>   path, when in the loopback mode, to return traffic to the sender of
>   that traffic.
> 

>   [...]
> 
>   The management plane must ensure that the MEPs of a transport path
>   are locked before it requests setting a given node of that transport
>   path in loopback mode.

Sami: Aren't we saying that MEPs must exist for the transport path to lock the Path before putting in Loopback.
Sami: Then I would explicitly mention that, saying "MEPs must exist at the end points of a transport path and the management .."


Thanks,

Sami

> 
> Let me know.
> -m
> 
> Le 16/01/2013 22:07, Adrian Farrel a écrit :
>> All, are we getting any closer to agreeing what we all intended to say?
>> 
>> Once we have that, I can work out what to do with the Errata Report.
>> 
>> Thanks,
>> Adrian
>> 
>>> -----Original Message-----
>>> From: David Ball [mailto:[e-mail]]
>>> Sent: 10 January 2013 17:57
>>> To: VIGOUREUX, MARTIN (MARTIN)
>>> Cc: Sami Boutros (sboutros); [e-mail]; Siva Sivabalan (msiva);
>>> [e-mail]; [e-mail]; Stewart Bryant (stbryant);
>>> [e-mail]; George Swallow (swallow); [e-mail]; [e-mail]
>>> Subject: Re: [Editorial Errata Reported] RFC6435 (3429)
>>> 
>>> Hi Martin,
>>> 
>>> Ah, right I see: since the loopback is locally configured, there is no
>>> need for a MEP/MIP to send/receive OAM frames - but there may be a
>>> MEP/MIP.
>>> 
>>> So would this work to clarify the text?
>>>   "It should be noted that the data-plane loopback function for a
>>>    given transport path can be applied to data-plane loopback points
>>>    residing on interfaces where there may be no corresponding MEP or
>>>    MIP."
>>> 
>>> For completeness, the references to "MEP or MIP" in paragraphs 3 and 7
>>> of section 4 would also need to be changed, to instead refer to the
>>> transport path that is being put in to loopback.
>>> 
>>> As another data point, I found this text in RFC6371 section 6.3.2:
>>>   "It should be noted that data-plane loopback function itself is
>>>    applied to data-plane loopback points that can reside on different
>>>    interfaces from MIPs/MEPs."
>>> Note the critical difference compared to RFC6435: "that can reside"
>>> instead of "residing".
>>> 
>>> Thanks
>>> 
>>> 
>>> 	David
>>> 
>>> 
>>> On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote:
>>>> Sami,
>>>> 
>>>> Thanks. Yet, I am not sure David's interpretation and mine exactly match.
>>>> David, correct me if I am wrong. For me it says that we can do
>>>> loopback on different interfaces (for different LSPs) but implies that
>>>> there is a mip/mep for that lsp on that interface, while my
>>>> interpretation is that the presence of a mip/mep for that lsp on that
>>>> interface is not needed.
>>>> 
>>>> -m
>>>> ________________________________
>>>> De : Sami Boutros (sboutros)
>>>> Envoy? : 09/01/2013 19:00
>>>> ? : VIGOUREUX, MARTIN (MARTIN)
>>>> Cc : [e-mail]; David Ball -X (daviball - Ensoft Ltd at Cisco);
>> Siva
>>> Sivabalan (msiva); [e-mail]; [e-mail]; Stewart
>>> Bryant (stbryant); [e-mail]; George Swallow (swallow); [e-mail];
>>> [e-mail]
>>>> Objet : Re: [Editorial Errata Reported] RFC6435 (3429)
>>>> 
>>>> 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.
>>>>> 
>>>>> I'd welcome the views/souvenirs of my co-authors.
>>>>> 
>>>>> -m
>>>>> 
>>>>> Le 12/12/2012 19:17, Adrian Farrel a ?crit :
>>>>>> 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
>>>>>> 
>>>>>> 
>>>> 
>>> 
>>> --
>>> David Ball
>>> <[e-mail]>
>> 
>> 
>>