Subject: [mpls] WGLC for draft-ietf-mpls-bfd-directed

From: <[email-masked]>
Date: Wed, 24 May 2017 09:33:21 +0000

Dear Working Group,

The authors have updated draft-ietf-mpls-bfd-directed and think that the draft is ready for WGLC.
Therefore this e-mail starts a WG LC which will end on the 7th of June.

Please note that draft-ietf-mpls-bfd-directed did not pass the
previous working group last call, because of an IPR disclosure:

  https://datatracker.ietf.org/ipr/2892/

The authors have updated the draft and they believe that the IPR is no longer in scope.
Please notify the list if you still think the IPR is an issue and please state if you think it
is OK to continue with the publication of this document.

  Best regards

    Nic

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 May 2017 21:22:25 +0800

Hi Nick,
I don't know of any IETF regulations or rules that prescribe to prevent
progressing a document based on type of IPR Disclosure. I'd note that
authors did their best to ensure that appropriate IPR Disclosures were
filed as soon as possible. I believe that there were no concerns regarding
timing of the IPR Disclosures related to earlier versions of the draft.

Regards,
Greg

On Wed, May 24, 2017 at 5:33 PM, <[email-masked]> wrote:

>   *https://datatracker.ietf.org/ipr/2892/*
> <https://datatracker.ietf.org/ipr/2892/>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 May 2017 21:35:33 +0800

Support as co-author

The question whether the  previously disclosed IPR is applicable to the
current version of the draft, in my view, should be evaluated by the holder
of the IPR. To the best of my understanding, the IPR is not applicable.

Regards,
Greg

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 24 May 2017 15:36:41 +0000

Nic,

I do not support advancing this document in its current form. It has many technical deficiencies, some of which are listed and described below.

I also believe your WGLC note should have been much more detailed and comprehensive.

I believe this is the 3rd WGLC on this document, correct? (That gives a new meaning to “Last” :-) If so, that should have also been clarified in the WGLC email, with a much more clear explanation and comprehensive set of details of how concerns were discussed and addressed.

> The authors have updated draft-ietf-mpls-bfd-directed and think that the draft is ready for WGLC.

I am very concerned that there was no discussion on the list of any of those changes.  The authors believe the draft is ready — do you believe so as well, Nic? Was a shepherd review performed and is that available?

> previous working group last call, because of an IPR disclosure:

Is that the 1st or 2nd WGLC? I think this statement is an oversimplification. There were many technical concerns. 

Anyway, scanning through this document, some technical issues:

1. This approach assumes that FECs do not ever change. A reverse path is instructed at setup/bootstrap with MPLS LSP Ping — what happens if paths change?!? If a return tunnel is suddenly deleted from underneath?
2. “Case of MPLS Data Plane” — is there any other non-MPLS case? This points to the fact of lack of review and editorial sloppiness.
3. “Exactly one sub-TLV MUST be included in the Reverse Path TLV.” — so basically, no Tunnels can be return path?!?
4. The “Use Case Scenario” uses 2119 language in a way that does not make sense.

Please note, this is not an exhaustive list, but a 2 minute scan through the doc.

Thanks!

Carlos.

> On May 24, 2017, at 2:33 AM, [email-masked] <[email-masked]> wrote:
> 
> Dear Working Group,
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 25 May 2017 22:26:38 +0800

Dear Carlos,
thank you for taking two minutes to write the message. From it all I've
found only one concern that, in my view, may be considered technical. Thus
I'll bring it to the forefront and will try to explain how the situation
may be handled.
You wrote:
1. This approach assumes that FECs do not ever change. A reverse path is
instructed at setup/bootstrap with MPLS LSP Ping — what happens if paths
change?!? If a return tunnel is suddenly deleted from underneath?
I consider it to be the case that should be handled by properly operating
the network rather then auto-discovering it and auto-recovering. I hardly
believe that a tunnel may be "suddenly deleted" without the operator being
aware of that. And if that is the case, then the operator may proactively
re-signal return path for those BFD sessions that may be affected by the
planned change in the network. Even more, BFD sessions to decrease chance
of receiving false negative during period the remote BFD peer switches to
new recommended path.

Thank you for the editorial suggestion to consider renaming the section.
We'll discuss and share our proposal to improve the wording.

Others may decide to respond to the rest of your message. There's nothing
of technical substance, as I see it.

Regards,
Greg

On Wed, May 24, 2017 at 11:36 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Nic,
>
> I do not support advancing this document in its current form. It has many
> technical deficiencies, some of which are listed and described below.
>
> I believe this is the 3rd WGLC on this document, correct? (That gives a
> new meaning to “Last” :-) If so, that should have also been clarified in
> the WGLC email, with a much more clear explanation and comprehensive set of
> details of how concerns were discussed and addressed.
>
> I am very concerned that there was no discussion on the list of any of
> those changes.  The authors believe the draft is ready — do you believe so
> as well, Nic? Was a shepherd review performed and is that available?
>
> Is that the 1st or 2nd WGLC? I think this statement is an
> oversimplification. There were many technical concerns.
>
> 1. This approach assumes that FECs do not ever change. A reverse path is
> instructed at setup/bootstrap with MPLS LSP Ping — what happens if paths
> change?!? If a return tunnel is suddenly deleted from underneath?
> 2. “Case of MPLS Data Plane” — is there any other non-MPLS case? This
> points to the fact of lack of review and editorial sloppiness.
> 3. “Exactly one sub-TLV MUST be included in the Reverse Path TLV.” — so
> basically, no Tunnels can be return path?!?

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 26 May 2017 17:14:43 -0400

Greg,

Anytime — I wanted to reply so that there was at least one non-author message about it.  You and I have very different views on what is a technical concern.

For example this comment describes a specific technical concern:
* “Exactly one sub-TLV MUST be included in the Reverse Path TLV.”

Basically, the document says that the return path cannot have a FEC Stack (e.g., nested FECs or a Tunnel or...). It is not clear why. 
Basically it flattens MPLS to one label on return.

In contrast, RFC 7110 allows for multiple FECs:

   Reply Path:  It is used to describe the return path that an echo
      reply will be send along.  It is variable in length and can
      contain zero, one or more Target FEC sub-TLVs [RFC4379].

A second technical issue:
* “ This approach assumes that FECs do not ever change….”

I find the response of “punt it to the operator” complete unsatisfactory. We are trying to reduce OpEx, not build tools that put the burden on operators.

Basically, the root cause stems from the fact that RFC 7110 uses a return path construct for a response immediate sent and elicited by the reply, whereas your draft attempts to mimic the method but for a protocol in which there is a bootstrapping, and after that, no mechanism for update although the underlying network can change.

This proposal as it is right now, basically makes an existing protocol more brittle than it was before, and the network operations more complex.

Another technical concern, the description in Section 4. And then there’s also the indication of IPR but a conflicting message from one of the authors.

Please note I was not making specific suggestions — technical or editorial. Just pointing out that there are technical issues with this document.

Technically.

— Carlos.

> On May 25, 2017, at 10:26 AM, Greg Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Dear Carlos,
> thank you for taking two minutes to write the message. From it all I've found only one concern that, in my view, may be considered technical. Thus I'll bring it to the forefront and will try to explain how the situation may be handled.
> You wrote:
> I consider it to be the case that should be handled by properly operating the network rather then auto-discovering it and auto-recovering. I hardly believe that a tunnel may be "suddenly deleted" without the operator being aware of that. And if that is the case, then the operator may proactively re-signal return path for those BFD sessions that may be affected by the planned change in the network. Even more, BFD sessions to decrease chance of receiving false negative during period the remote BFD peer switches to new recommended path.
> 
> Thank you for the editorial suggestion to consider renaming the section. We'll discuss and share our proposal to improve the wording.
> 
> Others may decide to respond to the rest of your message. There's nothing of technical substance, as I see it.
> 
> Regards,
> Greg
> 
> On Wed, May 24, 2017 at 11:36 PM, Carlos Pignataro (cpignata) <[email-masked] <mailto:[email-masked]>> wrote:
> Nic,
> 
> > On May 24, 2017, at 2:33 AM, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Dear Working Group,
> >
> >   https://datatracker.ietf.org/ipr/2892/ <https://datatracker.ietf.org/ipr/2892/>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 31 May 2017 12:29:52 +0800

Hi Carlos,
we clearly have different interpretation of what operational simplicity
means. Of course, someone may come up with mechanism to monitor the reverse
path of the BFD session that was set according to BFD Reverse Path TLV but
I don't see that neither necessary, nor helpful because that may hide from
an operator real failure.
Regarding the number of sub-TLVs in BFD Reverse Path TLV. I can assume that
authors followed in the path of reasoning set by RFC 4379 (now RFC 8029).
RFC 8029 defines procedures to verify correlation between the MPLS data
plane and control plane. In example in Section 3.2 we see that listing all
FECs is optional and it is perfectly valid to include single FEC that
characterizes the outer MPLS label. Using the same approach in RFC 7110, in
my opinion, was not only right but necessary. But for case of controlling
the reverse direction of a BFD session that seems unnecessary.
Additionally, RFC 7110 allows operator to pass the right for the final
selection of the return path for Echo Reply to the egress node, to the
responder. That may be useful for Echo Request/Reply as the egress returns
information on how it concluded the selection process based on received
Reply Path TLV. For BFD Reverse Path TLV, egress uses Return Code and
Return Sub-code in Echo Reply to indicate whether the requested path is
available to the egress node. If the path is not available, then the
operator may send another request in LSP Ping using BFD Reverse Path TLV.

Regards,
Greg

On Sat, May 27, 2017 at 5:14 AM, Carlos Pignataro <[email-masked]>
wrote:

> Greg,
>
> Anytime — I wanted to reply so that there was at least one non-author
> message about it.  You and I have very different views on what is a
> technical concern.
>
> Basically, the document says that the return path cannot have a FEC Stack
> (e.g., nested FECs or a Tunnel or...). It is not clear why.
> I find the response of “punt it to the operator” complete unsatisfactory.
> We are trying to reduce OpEx, not build tools that put the burden on
> operators.
>
> Basically, the root cause stems from the fact that RFC 7110 uses a return
> path construct for a response immediate sent and elicited by the reply,
> whereas your draft attempts to mimic the method but for a protocol in which
> there is a bootstrapping, and after that, no mechanism for update although
> the underlying network can change.
>
> This proposal as it is right now, basically makes an existing protocol
> more brittle than it was before, and the network operations more complex.
>
> Another technical concern, the description in Section 4. And then there’s
> also the indication of IPR but a conflicting message from one of the
> authors.
>
> Please note I was not making specific suggestions — technical or
> editorial. Just pointing out that there are technical issues with this
> document.
>
> Technically.
>
> — Carlos.
>
> On May 25, 2017, at 10:26 AM, Greg Mirsky <[email-masked]> wrote:
>
> Dear Carlos,

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 31 May 2017 13:33:17 +0800

Hi Carlos,
after more consideration realized that you have brought up valid concern
and I propose the following change to address it:

   - in section 3.1.1

OLD TEXT

Exactly one sub-TLV MUST be included in the Reverse Path TLV.
   If more than one sub-TLV is present in the Reverse Path TLV, then, in
   order to avoid ambiguity of which of TLVs to use, the egress BFD peer
   MUST send Echo Reply with the received Reverse Path TLVs and set the
   Return Code to "Too Many TLVs Detected" Section 3.2.

NEW TEXT

One or more sub-TLVs MAY be included in the BFD Reverse Path TLV.The
BFD Reverse Path TLV MAY list a stack of FECs that directly
corresponds to the label stack.

   - section 3.2 - remove the first bullet describing return code "Too
Many TLVs Detected"
   - section 5.2 - remove request to allocate return code value for
"Too Many TLVs Detected"

Hope these changes will address your concern.

Regards,

Greg

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 31 May 2017 11:29:50 +0000

Hi, Greg,

Thanks for the response! - even if it doesn't address the technical concerns. Sorry if I am not being clear enough or I cannot explain it better, but I do believe there are major unresolved technical issues.

To recap, this is just my technical opinion, and as my final response to this:
1. This draft forbids (in uppercase) the use of a stack in the return path. The explanation you gave is that "that seems unnecessary".
2. This draft does not specify procedures of what happens if the return specified FEC changes. Your response says "uses Return Code and Return Sub-code in Echo Reply" which is at bootstrap, but not what happens after the BFD session is up and the path changes (I.e. There's no more MPLS Ping)
3. For some reason you add "someone may come up with mechanism to monitor the reverse path of the BFD session" but that's what section 4 is doing.
4. Pushing the operator to make more decisions and take more actions does not simplify.

Net-net: makes bfd more brittle (was this run by the BFD WG?)

Thanks!

Carlos.

Sent from my iPad

On May 31, 2017, at 12:29 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
we clearly have different interpretation of what operational simplicity means. Of course, someone may come up with mechanism to monitor the reverse path of the BFD session that was set according to BFD Reverse Path TLV but I don't see that neither necessary, nor helpful because that may hide from an operator real failure.
Regarding the number of sub-TLVs in BFD Reverse Path TLV. I can assume that authors followed in the path of reasoning set by RFC 4379 (now RFC 8029). RFC 8029 defines procedures to verify correlation between the MPLS data plane and control plane. In example in Section 3.2 we see that listing all FECs is optional and it is perfectly valid to include single FEC that characterizes the outer MPLS label. Using the same approach in RFC 7110, in my opinion, was not only right but necessary. But for case of controlling the reverse direction of a BFD session that seems unnecessary.
Additionally, RFC 7110 allows operator to pass the right for the final selection of the return path for Echo Reply to the egress node, to the responder. That may be useful for Echo Request/Reply as the egress returns information on how it concluded the selection process based on received Reply Path TLV. For BFD Reverse Path TLV, egress uses Return Code and Return Sub-code in Echo Reply to indicate whether the requested path is available to the egress node. If the path is not available, then the operator may send another request in LSP Ping using BFD Reverse Path TLV.

Regards,
Greg

On Sat, May 27, 2017 at 5:14 AM, Carlos Pignataro <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Technically.

— Carlos.

On May 25, 2017, at 10:26 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Dear Carlos,

Regards,
Greg

On Wed, May 24, 2017 at 11:36 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Nic,

Thanks!

Carlos.

> On May 24, 2017, at 2:33 AM, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> wrote:
>
> Dear Working Group,
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 31 May 2017 22:52:55 +0800

Hi Carlos,
please find my answers in-line tagged GIM>>.

Regards,
Greg

On Wed, May 31, 2017 at 7:29 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Hi, Greg,
>
> Thanks for the response! - even if it doesn't address the technical
> concerns. Sorry if I am not being clear enough or I cannot explain it
> better, but I do believe there are major unresolved technical issues.
>
> 1. This draft forbids (in uppercase) the use of a stack in the return
> path. The explanation you gave is that "that seems unnecessary".
>
GIM>> Please consider this mail
<https://www.ietf.org/mail-archive/web/mpls/current/msg16785.html>. I hope
it addresses this concern.

> 2. This draft does not specify procedures of what happens if the return
> specified FEC changes. Your response says "uses Return Code and Return
> Sub-code in Echo Reply" which is at bootstrap, but not what happens after
> the BFD session is up and the path changes (I.e. There's no more MPLS Ping)
>
GIM>> As I've noted, if the change results from the planned operation,
then, I believe, the operator may take precautionary actions to re-signal
new reverse path for BFD sessions that will be affected.

> 3. For some reason you add "someone may come up with mechanism to monitor
> the reverse path of the BFD session" but that's what section 4 is doing.
>
GIM>> The proposal is to add optional mechanism to direct the reverse
direction of the BFD session. The proposed mechanism is not intended to
serve as failure localization and characterization tool. In that regard
I've suggested that some other mechanism may be used. After all, if the
chosen return path deemed unstable, then another may be signaled using the
described mechanism.

> 4. Pushing the operator to make more decisions and take more actions does
GIM>> What can be expressed as data model, I believe, can then be used in
flow of orchestrating network.

> On May 31, 2017, at 12:29 AM, Greg Mirsky <[email-masked]> wrote:
>
> Hi Carlos,
> Regarding the number of sub-TLVs in BFD Reverse Path TLV. I can assume
> that authors followed in the path of reasoning set by RFC 4379 (now RFC
> 8029). RFC 8029 defines procedures to verify correlation between the MPLS
> data plane and control plane. In example in Section 3.2 we see that listing
> all FECs is optional and it is perfectly valid to include single FEC that
>>> I do not support advancing this document in its current form. It has
>>> many technical deficiencies, some of which are listed and described below.
>>>