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

["VIGOUREUX, MARTIN (MARTIN)" <[e-mail]>]

David,

Yes it does. Thanks.
I first thought of removing all references to MEP/MIP but should have given it a second thought.

-m
________________________________
De : David Ball
Envoyé : 17/01/2013 18:41
À : VIGOUREUX, MARTIN (MARTIN)
Cc : [e-mail]; 'Sami Boutros (sboutros)'; '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)

Hi Martin,

Actually I think the last paragraph is talking about something different
again: this is the MEPs that must be locked.

Here is a transport path:

  |>-------x----------x-------<|
            --------->|
            <---------v
  A        B          C        D

A and D are the MEPs; B is the source of the test, C is the loopback
point.

As we have discussed, C could be a MIP, could be the MEP at D, or could
be at a point that is neither a MIP or a MEP.

A and D are the MEPs that must be locked during the test.

My question was about point B: I think in the original text point B must
always be the same as the MEP at point A; your proposal allows it to be
some other point, eg at a MIP or at a point where there is no MIP or
MEP.

If we keep the original text about point B, and just change the text
about point C, then combining with your proposal we get the following
change:

Old text:
   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.

New text:
   The loopback function is used to test the integrity of a transport
   path from a MEP to any other node along the same transport path.
   This is achieved by setting the target node into loopback mode for
   that transport path, and  transmitting a pattern of test data from
   the MEP.  The target node loops all data received on the transport
   path back towards the sending MEP, which extracts the test data
   and compares it with what it sent.

   Loopback is a function that enables a given node of a transport
   path to return traffic to the sending MEP for that transport path
   when in the loopback mode.

   [...]

   The management plane must ensure that the MEPs at either end of a
   transport path are locked before it requests setting a given node of
   that transport path into loopback mode.

Does this work?


        David


On Thu, Jan 17, 2013, Martin Vigoureux wrote:
> David,
>
> agreed, and in fact this is consistent with the fact I kept MEP in
> the last paragraph I changed.
>
> -m
>
>
> Le 17/01/2013 18:09, David Ball a ?crit :
> >Thanks Martin.
> >
> >Regarding the first paragraph, I agree with your change to add "for that
> >transport path", that does make it clearer.
> >
> >Regarding the other paragraphs: We have agreed that the intent was that
> >the point doing the loopback does not have to be a MEP or MIP, but your
> >proposal also seems to change it so that the point transmitting the
> >test data does not have to be a MEP.  I think the original text was
> >consistent that the test was done *from* a MEP; the question was whether
> >it was done from a MEP *to another MEP/MIP*, or from a MEP *to an
> >arbitrary point*.
> >
> >So you might be right that the text describing the source of the test
> >should also be changed, but I think that is a slightly separate issue.
> >It is probably safest to keep the changes to a minimum and just fix the
> >description of the point that is doing the loopback, ie the target of
> >the test.
> >
> >Do you agree?
> >
> >
> >     David
> >
> >
> >On Thu, Jan 17, 2013, 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.
> >>
> >>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, 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
> >>    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.
> >>
> >>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]>
> >>>
> >>>
> >>>
> >

--
David Ball
<[e-mail]>