Re: [mpls] Review of draft-mirsky-mpls-bfd-bootstrap-clarify

+bfd WG.

Some original comments to Adrian were:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/SYouXfNrVyKHErqacOuM2fICzMc/ <https://mailarchive.ietf.org/arch/msg/rtg-bfd/SYouXfNrVyKHErqacOuM2fICzMc/>

Apparently, Greg didn't consider this worth holding his peace over.

https://www.rfc-editor.org/errata/eid5085 <https://www.rfc-editor.org/errata/eid5085> was filed and accepted as a clarification for RFC 5884 as part of a prior round of this discussion.

LSP Ping is getting its norao update currently in MPLS.  While it's my opinion that the current set of changes to that document don't negatively impact backward compatibility with RFC 5884, it's a normative enough change that perhaps it's worth moving forward with the small updates to RFC 5884.

In my opinion, the appropriate work is to take this to BFD for RFC 5884-bis, which would be co-reviewed with MPLS.  I believe we can get at least one of the original authors to pick up that work.

That said, the BFD chairs are completely unaware of anyone experiencing any sort of confusion covering RFC 5884 procedures other than Greg.

-- Jeff

> On Jan 24, 2024, at 2:55 PM, Carlos Pignataro <cpignata@gmail.com> wrote:
> 
> Hi!
> 
> Review of draft-mirsky-mpls-bfd-bootstrap-clarify
> Version 05
> Type Getting Ready for WG Adoption
> Team MPLS WG Review Team
> Reviewer: Carlos Pignataro 
> 
> I have been asked to provide a ‘getting ready for WG adoption’ review of this document, on behalf of the MPLS WG review team.
> 
> There are generally two relevant questions at this stage:
> 
> 1. knowing whether the document is in scope for the working group, and
> 2. knowing whether the document is ready to be considered for WG adoption
> 
> My perspective is that:
> 
> 1. Maybe - RFC 4884, the RFC that this document would update if approved, was progressed as draft-ietf-bfd-mpls in the bfd wg. As such, I wonder if that ought to be followed here. From a practical standpoint, both WGs (mpls and bfd) would have to review this document, but it is a chair decision and guidance whether this should live in mpls or bfd (and frankly I have no strong position either way so long as both WGs are in the loop, simply pointing historic datapoints.) The document is clearly in scope on the intersection of both WGs, and historically was in bfd.
> 
> 2. Yes – this document addresses clear clarifications for implementation interoperability. Granted, this protocol is deployed without these clarifications, but are (at least) theoretical gaps.
> 
> A couple of further comments, since I read the document. Overall, well written and clear, achieves its goal, and:
> 
> a. Backwards compatibility is paramount, and neither of those two words appear in the document. I recommend a section detailing implications.
> 
> b. Section 5, IPv6, seems like an after-though, since it is not mentioned in the Abstract. Further, that case and explanation is well covered in RFC 8029, and as such seems like a distraction.
> 
> c. There are various nits and an editorial pass would help with clarity. These include things like unqualified “echo reply” uses.
> 
> Thanks,
> 
> Carlos Pignataro
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls