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

👍🏼

Carlos Pignataro reacted via Gmail
<https://www.google.com/gmail/about/?utm_source=gmail-in-product&utm_medium=et&utm_campaign=emojireactionemail#app>

On Mon, Feb 5, 2024 at 1:40 AM <xiao.min2@zte.com.cn> wrote:

> The suggestion from Jeff and Carlos seems reasonable to me, although I was
> not involved in the former mailing-list discussion.
>
>
> Best Regards,
>
> Xiao Min
> Original
> *From: *CarlosPignataro <cpignata@gmail.com>
> *To: *Jeff Haas <jhaas@pfrc.org>;
> *Cc: *mpls@ietf.org <mpls@ietf.org>;rtg-bfd@ietf. <rtg-bfd@ietf.org>;
> *Date: *2024年02月05日 11:35
> *Subject: **Re: [mpls] Review of draft-mirsky-mpls-bfd-bootstrap-clarify*
> Thanks Jeff for refreshing the cache on those mailing-list comments.
> I was part of that conversation, and frankly did not remember them — now I
> do. And to put that in perspective, that was almost 6 **years** ago!
>
> I also missed the Errata, which was good.
> And there’s also a couple other held for doc update:
> https://www.rfc-editor.org/errata_search.php?rfc=5884
>
> I will start with the last bit, borrowing from your text Jeff: Carlos is
> also completely unaware of anyone experiencing any sort of confusion
> covering RFC 5884 procedures other than Greg.
>
> And also, it’s a clarification that does not hurt.
>
> I do not feel norao impacts 5884, but at the same time bundling all the
> updates on a RFC 5884-bis sounds like a most appropriate suggestion to me.
> I’m happy to help if needed.
>
> And to that, I’d also bundle in the changes from RFC 7726.
>
> Thanks,
>
> Carlos.
>
>
> On Feb 4, 2024, at 11:36 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>
> +bfd WG.
>
> Some original comments to Adrian were:
>
> 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 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
>
>
>
>
>