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

From: "VIGOUREUX, MARTIN (MARTIN)" <[email-masked]>
Date: Wed, 9 Jan 2013 21:29:56 +0100

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 : [email-masked]; David Ball -X (daviball - Ensoft Ltd at Cisco); Siva Sivabalan (msiva); [email-masked]; [email-masked]; Stewart Bryant (stbryant); [email-masked]; George Swallow (swallow); [email-masked]; [email-masked]
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:[email-masked]]
>>> Sent: 12 December 2012 17:45
>>> To: [email-masked]; [email-masked]; [email-masked];
>>> [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked]; [email-masked];
>>> [email-masked]
>>> Cc: [email-masked]; [email-masked]; [email-masked]
>>> 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<[email-masked]>
>>>
>>> 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
>>
>>

---

From: Yuji Tochio <[email-masked]>
Date: Thu, 10 Jan 2013 16:03:09 +0900

Hi

In my understanding, the text proposed by David says only loopback function
(i.e. a MEP or a MIP on an interface) and there is no description for loopback
point. So there is no impliaction that that there is a mip/mep for that lsp on
that interface and almost sync with Martin's interpretation.

This is why I suport for his proposal. David, please correct me if I am wrong.

Regards, Yuji

(2013/01/10 5:29), VIGOUREUX, MARTIN (MARTIN) wrote:
> 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
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
> Envoye' : 09/01/2013 19:00
> A` : VIGOUREUX, MARTIN (MARTIN)
> Cc : [email-masked]; David Ball -X (daviball - Ensoft Ltd at Cisco); Siva Sivabalan (msiva); [email-masked]; [email-masked]; Stewart Bryant
> (stbryant); [email-masked]; George Swallow (swallow); [email-masked]; [email-masked]
> > 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.
> >
> > Le 12/12/2012 19:17, Adrian Farrel a e'crit :
> >> Hello,
> >>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 10 Jan 2013 16:02:53 -0000

Martin,
 
Could you have a stab at drafting what you consider to be the correct text?
 
A
 
From: VIGOUREUX, MARTIN (MARTIN) [mailto:[email-masked]] 
Sent: 09 January 2013 20:30
To: Sami Boutros (sboutros)
Cc: [email-masked]; David Ball -X (daviball - Ensoft Ltd at Cisco); Siva
Sivabalan (msiva); [email-masked]; [email-masked]; Stewart Bryant
(stbryant); [email-masked]; George Swallow (swallow); [email-masked];
[email-masked]
Subject: RE: [Editorial Errata Reported] RFC6435 (3429)
 
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 : [email-masked]; David Ball -X (daviball - Ensoft Ltd at Cisco); Siva
Sivabalan (msiva); [email-masked]; [email-masked]; Stewart Bryant
(stbryant); [email-masked]; George Swallow (swallow); [email-masked];
[email-masked]
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.
>>> http://www.rfc-editor.org/errata_search.php?rfc=6435
<http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429> &eid=3429

---

From: David Ball <[email-masked]>
Date: Thu, 10 Jan 2013 17:56:57 +0000

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:
> 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
> Envoy? : 09/01/2013 19:00
> ? : VIGOUREUX, MARTIN (MARTIN)
> > Le 12/12/2012 19:17, Adrian Farrel a ?crit :
> >> Hello,
> >>

-- 
David Ball
<[email-masked]>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 16 Jan 2013 21:07:00 -0000

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

> From: David Ball [mailto:[email-masked]]
> Sent: 10 January 2013 17:57
> To: VIGOUREUX, MARTIN (MARTIN)
> Cc: Sami Boutros (sboutros); [email-masked]; Siva Sivabalan (msiva);
> [email-masked]; [email-masked]; Stewart Bryant (stbryant);
> [email-masked]; George Swallow (swallow); [email-masked]; [email-masked]
> Subject: Re: [Editorial Errata Reported] RFC6435 (3429)
> 
> Hi Martin,
> 
> Sivabalan (msiva); [email-masked]; [email-masked]; Stewart
> Bryant (stbryant); [email-masked]; George Swallow (swallow); [email-masked];
> [email-masked]
> > I agree with Martin, the text proposed by David describe more accurately
what
> we meant.
> > > 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

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 17 Jan 2013 13:57:55 +0100

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

---

From: "Sami Boutros (sboutros)" <[email-masked]>
Date: Thu, 17 Jan 2013 16:58:52 +0000

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

> 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"

>   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

Sami: 

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

Sami

>   are locked before it requests setting a given node of that transport

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

>> applied to

---

From: David Ball <[email-masked]>
Date: Thu, 17 Jan 2013 17:09:34 +0000

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:
> Le 16/01/2013 22:07, Adrian Farrel a ?crit :

-- 
David Ball
<[email-masked]>

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 17 Jan 2013 18:17:59 +0100

David,

agreed, and in fact this is consistent with the fact I kept MEP in the 
last paragraph I changed.

-m

---

From: "Sami Boutros (sboutros)" <[email-masked]>
Date: Thu, 17 Jan 2013 17:32:39 +0000

Martin,

I think the other paragraphs edits shouldn't be included in the ERRATA, the idea of sending test traffic not from a MEP we have not discussed before.

Thanks,

Sami
On Jan 17, 2013, at 9:17 AM, Martin Vigoureux wrote:

> David,
> 
> agreed, and in fact this is consistent with the fact I kept MEP in the last paragraph I changed.
> 
> -m
> 
>

---

From: "VIGOUREUX, MARTIN (MARTIN)" <[email-masked]>
Date: Thu, 17 Jan 2013 17:37:31 +0000

Sami,

That is what I have agreed to just below..

-m
________________________________
De : Sami Boutros (sboutros)
Envoyé : 17/01/2013 18:32
À : VIGOUREUX, MARTIN (MARTIN)
Cc : David Ball -X (daviball - Ensoft Ltd at Cisco); [email-masked]; Siva Sivabalan (msiva); [email-masked]; [email-masked]; Stewart Bryant (stbryant); [email-masked]; George Swallow (swallow); [email-masked]; [email-masked]
Objet : Re: [Editorial Errata Reported] RFC6435 (3429)

Martin,

Thanks,

Sami

---

From: David Ball <[email-masked]>
Date: Thu, 17 Jan 2013 17:41:02 +0000

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:

   [...]

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:
> Le 17/01/2013 18:09, David Ball a ?crit :
> >Thanks Martin.
> >

-- 
David Ball
<[email-masked]>

---

From: "VIGOUREUX, MARTIN (MARTIN)" <[email-masked]>
Date: Thu, 17 Jan 2013 19:59:53 +0000

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 : [email-masked]; 'Sami Boutros (sboutros)'; 'Siva Sivabalan (msiva)'; [email-masked]; [email-masked]; 'Stewart Bryant (stbryant)'; [email-masked]; 'George Swallow (swallow)'; [email-masked]; [email-masked]
Objet : Re: [Editorial Errata Reported] RFC6435 (3429)

Hi Martin,

Old text:

   [...]

New text:

   [...]

Does this work?

        David

--
David Ball
<[email-masked]>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Jan 2013 11:09:35 -0000

OK, when we are done, can some write me an email that contains the text that
would have been in the Errata Report if we had known then what we know now?
 
Then I will process the existing report and the new text.
 
Thanks,
Adrian
 
From: VIGOUREUX, MARTIN (MARTIN) [mailto:[email-masked]] 
Sent: 17 January 2013 20:00
To: David Ball
Cc: [email-masked]; 'Sami Boutros (sboutros)'; 'Siva Sivabalan (msiva)';
[email-masked]; [email-masked]; 'Stewart Bryant (stbryant)';
[email-masked]; 'George Swallow (swallow)'; [email-masked]; [email-masked]
Subject: RE: [Editorial Errata Reported] RFC6435 (3429)
 
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 : [email-masked]; 'Sami Boutros (sboutros)'; 'Siva Sivabalan (msiva)';
[email-masked]; [email-masked]; 'Stewart Bryant (stbryant)';
[email-masked]; 'George Swallow (swallow)'; [email-masked]; [email-masked]
Objet : Re: [Editorial Errata Reported] RFC6435 (3429)
Hi Martin,

Old text:

   [...]

New text:

   [...]

Does this work?

        David

On Thu, Jan 17, 2013, Martin Vigoureux wrote:
> >>>>have to admit that MIP and MEP are used in Section 4 of RFC6435, thus
surely
> >>>>causing confusion.
> >>>>>>>Authors of RFC 6435: I need to hear from you that you meant the text
that
> >>>>>>>>It should be noted that the data-plane loopback function may be
applied
> >>>at
> >>>>>>>>MIPs/MEPs on different interfaces, the corresponding loopback
functions
> >>>>would

-- 
David Ball
<[email-masked]>

---

From: David Ball <[email-masked]>
Date: Fri, 18 Jan 2013 12:42:28 +0000

Hi Adrian,

I think we are done, here is the updated text:

====

Section 4, paragraphs 2-7; old text:

   Loopback is a function that enables a receiving MEP or MIP to return
   traffic to the sending MEP when in the loopback state.  This state
   corresponds to the situation where, at a given node, a forwarding
   plane loop is configured, and the incoming direction of a transport
   path is cross-connected to the outgoing reverse direction.
   Therefore, except in the case of early TTL expiry, traffic sent by
   the source will be received by that source.

   Data-plane loopback is an out-of-service function, as required in
   Section 2.2.5 of RFC 5860 [1].  This function loops back all traffic
   (including user data and OAM).  The traffic can be originated from
   one internal point at the ingress of a transport path within an
   interface or inserted from an input port of an interface using
   external test equipment.  The traffic is looped back unmodified
   (other than normal per-hop processing such as TTL decrement) in the
   direction of the point of origin by an interface at either an
   intermediate node or a terminating node.

   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.  All traffic (including both payload and
   OAM) received on the looped back interface is sent on the reverse
   direction of the transport path.

   For data-plane loopback at an intermediate point in a transport path,
   the loopback needs to be configured to occur at either the ingress or
   egress interface.  This is done using management.

   The management plane can be used to configure the loopback function.
   The management plane must ensure that the two MEPs are locked before
   it requests setting MEP or MIP in the loopback state.

New text:

   Loopback is a function that enables a given node on a transport 
   path to return traffic to the sending MEP for that transport path 
   when in the loopback mode.  This mode corresponds to the situation 
   where, at a given node, a forwarding plane loop is configured, and 
   the incoming direction of a transport path is cross-connected to the 
   outgoing reverse direction.  Therefore, except in the case of early 
   TTL expiry, traffic sent by the source will be received by that 
   source.

   Data-plane loopback is an out-of-service function, as required in
   Section 2.2.5 of RFC 5860 [1].  This function loops back all traffic
   (including user data and OAM).  The traffic can be originated from
   one internal point at the ingress of a transport path within an
   interface or inserted from an input port of an interface using
   external test equipment.  The traffic is looped back unmodified
   (other than normal per-hop processing such as TTL decrement) in the
   direction of the point of origin by an interface at either an
   intermediate node or a terminating node.

   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 MEP or MIP for that 
   transport path.

   For data-plane loopback at an intermediate point in a transport path,
   the loopback needs to be configured to occur at either the ingress or
   egress interface.  This is done using management.

Notes:

   The existing text has caused confusion about exactly where the 
   loopback is applied.  It does not clearly express the original 
   intent, which was that there may or may not be a MEP or MIP at the 
   loopback point.  In particular, paragraphs 2 and 7 imply that the 
   loopback point must be at a MEP or MIP, while paragraph 5 implies 
   that loopback is performed at a point where there is no MEP or MIP.

   The new text updates paragraphs 2, 3, 5 and 7 to clarify that the 
   loopback may be performed at any point along the transport path, 
   whether or not there is a MEP or MIP there, and that the loopback 
   only applies to the transport path in question.  Paragraphs 4 and 6 
   are unchanged.

====

	David

On Fri, Jan 18, 2013, Adrian Farrel wrote:
> Envoy? : 17/01/2013 18:41

-- 
David Ball
<[email-masked]>

---

From: "Sami Boutros (sboutros)" <[email-masked]>
Date: Fri, 18 Jan 2013 14:33:14 +0000

Looks good to me.

I agree that in the new text it is clear that we are not requiring a MIP or MEP at the node that perform the loopback function along the transport path

As well I feel it is clear the way I read it, that 

1- A MEP is required as a must at both ends of the transport path to perform the transport path lock function prior to setting up the loopback on a node along the transport path.
2- The Loopback function MUST be done via management only.

If the above is not clear to others while reading the new text, then we may need to update it.

Thanks,

Sami

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 18 Jan 2013 20:28:52 +0000

Hi Sami,
I think that the "This is done using management." can not and should not be interpreted as "The Loopback function MUST be done via management only." I would ask you to consider changing it to "This can be done using management plane.", thus leaving non-management means for further consideration.

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sami Boutros (sboutros)
Sent: Friday, January 18, 2013 6:33 AM
To: David Ball -X (daviball - Ensoft Ltd at Cisco)
Cc: <[email-masked]>; <[email-masked]>; Siva Sivabalan (msiva); <[email-masked]>; <[email-masked]>
Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429)

Looks good to me.

Thanks,

Sami

>> OK, when we are done, can some write me an email that contains the
>> text that would have been in the Errata Report if we had known then what we know now?
>>
>> From: VIGOUREUX, MARTIN (MARTIN)
>> [mailto:[email-masked]]
>> Cc: [email-masked]; 'Sami Boutros (sboutros)'; 'Siva Sivabalan
>> (msiva)'; [email-masked]; [email-masked]; 'Stewart
>> Bryant (stbryant)'; [email-masked]; 'George Swallow (swallow)';
>> [email-masked]; [email-masked]
>> Cc : [email-masked]; 'Sami Boutros (sboutros)'; 'Siva Sivabalan
>> (msiva)'; [email-masked]; [email-masked]; 'Stewart
>> Bryant (stbryant)'; [email-masked]; 'George Swallow (swallow)';
>> [email-masked]; [email-masked] Objet : Re: [Editorial Errata
>> Reported] RFC6435 (3429) Hi Martin,
>>
>> 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.
>>
>> 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.
>>
>>>> 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
>>>>
>>>>
>>>>> s/may be no corresponding MEP or MIP./may be no MEP or MIP for
>>>>> that transport path./ but this is optional.
>>>>>
>>>>>>> Cc: Sami Boutros (sboutros); [email-masked]; Siva Sivabalan
>>>>>>> (msiva); [email-masked]; [email-masked]; Stewart
>>>>>>> Bryant (stbryant); [email-masked]; George Swallow (swallow);
>>>>>>> [email-masked]; [email-masked]
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>> 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 :
>>>>>>>> [email-masked]; David Ball -X (daviball - Ensoft Ltd at
>>>>>>>> Cisco);
>>>>>> Siva
>>>>>>> Sivabalan (msiva); [email-masked]; [email-masked];
>>>>>>> Stewart Bryant (stbryant); [email-masked]; George Swallow (swallow);
>> [email-masked];
>>>>>>> [email-masked]
>>>>>>>>> what I think we meant here was that a loop-back function could
>>>>>>>>> be done
>> on
>>>>>>>>>> suggests. It is very clearly not what you wrote and, if you
>>>>>>>>>> meant
>>>>>> something
>>>>>>>>>> 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
>>>>>>>>>>> To: [email-masked]; [email-masked];
>>>>>>>>>>> [email-masked]; [email-masked];
>>>>>>>>>>> [email-masked]; [email-masked];
>>>>>>>>>>> [email-masked]; [email-masked];
>>>>>>> [email-masked];
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> 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
>>>>>>>>>>> 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.
>>>>>>>>>>>