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 <cpign...@gmail.com>
To: Jeff Haas <jh...@pfrc.org>;
Cc: m...@ietf.org <m...@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 <jh...@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 <cpign...@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
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Reply via email to