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

[Carlos Pignataro <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>> 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:
> 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) <[e-mail] <mailto:[e-mail]>> 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 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?
> 
> > Please note that draft-ietf-mpls-bfd-directed did not pass the
> > 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, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>> wrote:
> >
> > 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/ <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
> >
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
> 
> _______________________________________________
> mpls mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
>