Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multi-Point MPLS Label Switched Path (LSP)
draft-ietf-mpls-p2mp-bfd-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2025-02-17
|
10 | Éric Vyncke | [Ballot comment] Thanks for addressing my previous DISCUSS by requesting an IPv6 Dummy prefix to the IANA. For archiving the DISCUSS was: https://mailarchive.ietf.org/arch/msg/mpls/6sLqVwgLk8lUF0W1Imjk7OuHSQM/ Nevertheless some … [Ballot comment] Thanks for addressing my previous DISCUSS by requesting an IPv6 Dummy prefix to the IANA. For archiving the DISCUSS was: https://mailarchive.ietf.org/arch/msg/mpls/6sLqVwgLk8lUF0W1Imjk7OuHSQM/ Nevertheless some non-blocking COMMENTS to be addressed now or before AUTH48. ## NEW COMMENTS (non-blocking) ### Section 1 There is a repetition in `Hence, IANA is requested to allocate TBA2/64 range as a new Dummy IPv6 Prefix range *TBA2/64* (Section 7.1) ` ;-) ### Section 3.1 No need to refer to RFC when writing the IPv6 address in canonical format in `0:0:0:0:0:ffff:7f00/104 range *(see Section 5 of [RFC5952])*.` ### Somewhere It would be nice to mention that the use of a source-only IPv6 dummy address as the destination is on purpose to generate an exception and a return message. ## OLD COMMENTS (non-blocking) ### Abstract and Section 1 s/recommends the use of *an* IPv6 loopback address/recommends the use of *the* IPv6 loopback address/ ### Section 2.1 Suggest adding a reference (or a definition) of `G-ACh`. ### Section 3.1 Please use section 5 of RFC 5952 for `0:0:0:0:0:FFFF:7F00/104`. ### Section 3.2 In figure 1, some fields have a length that is specified and others have no length... Is it on purpose ? Even if the reader could guess, what are the expected sender/receiver behavior for the reserved fields ? ## NITS (non-blocking / cosmetic) ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-) |
2025-02-17
|
10 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss |
2025-02-17
|
10 | (System) | Changed action holders to Jim Guichard (IESG state changed) |
2025-02-17
|
10 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2025-02-17
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2025-02-17
|
10 | Greg Mirsky | New version available: draft-ietf-mpls-p2mp-bfd-10.txt |
2025-02-17
|
10 | (System) | New version approved |
2025-02-17
|
10 | (System) | Request for posting confirmation emailed to previous authors: Donald Eastlake , Greg Mirsky , Gyan Mishra |
2025-02-17
|
10 | Greg Mirsky | Uploaded new revision |
2025-01-10
|
09 | (System) | Changed action holders to Donald Eastlake, Greg Mirsky, Gyan Mishra (IESG state changed) |
2025-01-10
|
09 | Jim Guichard | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2025-01-09
|
09 | Jenny Bui | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2025-01-08
|
09 | Murray Kucherawy | [Ballot comment] Question #11 of the shepherd writeup doesn't explain why the selected status is the right one. I support Eric's DISCUSS position. |
2025-01-08
|
09 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2025-01-08
|
09 | Erik Kline | [Ballot comment] # Internet AD comments for draft-ietf-mpls-p2mp-bfd-09 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments … [Ballot comment] # Internet AD comments for draft-ietf-mpls-p2mp-bfd-09 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S1 * I'm in the camp of folks who consider it a bit of an abomination that nodes are sending packets with ::1 in any of the address fields (however many layers of encapsulation there are on the wire) outside of the local node. That said, I'm well aware that this has been a practice for BFD/OAM/... purposes (I raised this concern on MPLS LSP Ping document a while ago). I propose we consider a very short document in 6MAN/IPPM/wherever that: * requests allocation of an IPv6 Special-Purpose address * the intended usage would be for it to be assigned to any loopback interface on nodes wishing to do these kinds of stuff control plane monitoring or measuring traffic * we can ask for ::2/128; failing that, ::/8 is vast and I'm sure we could find something suitable. ### S3.1 * I'm afraid I have to disagree with my INT AD colleague: 0:0:0:0:0:FFFF:7F00 is perfectly okay to be written ::ffff:127.0.0.0. In fact, RFC 5952 Section 5 RECOMMENDs mixed notation where it's important to convey that there is an embedded IPv4 address. Over and above that, RFC 5952 Section 4.3 is pretty clear about MUST use lowercase ("f" and not "F"). Super in-the-weeds, I know. |
2025-01-08
|
09 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2025-01-08
|
09 | Warren Kumari | [Ballot comment] Thank you for this document - I found it interesting. Also, a good catch by Eric Vyncke on the ::1/128 issue - I … [Ballot comment] Thank you for this document - I found it interesting. Also, a good catch by Eric Vyncke on the ::1/128 issue - I completely missed that! Also much thanks to Bo Wu for the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-mpls-p2mp-bfd-08-opsdir-lc-wu-2025-01-02/) -- as Loa said in their response "Nice review.". Also thank to the authors for addressing the comments quickly and comprehensively. |
2025-01-08
|
09 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2025-01-08
|
09 | Zaheduzzaman Sarker | [Ballot comment] Supporting Eric's discuss. |
2025-01-08
|
09 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2025-01-07
|
09 | Roman Danyliw | [Ballot comment] Thank you to Meral Shirazipour for the GENART review. |
2025-01-07
|
09 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2025-01-07
|
09 | John Scudder | [Ballot comment] Thanks for this document, which I found straightforward to review with one exception, noted below. (Sorry, I missed pasting my final point. Reissuing … [Ballot comment] Thanks for this document, which I found straightforward to review with one exception, noted below. (Sorry, I missed pasting my final point. Reissuing my ballot to correct.) ### Section 1, unicast? [RFC8562] defines a method of using Bidirectional Detection (BFD) [RFC5880] to monitor and detect unicast failures between the sender (head) and one or more receivers (tails) in multipoint or multicast networks. I don't understand the use of the word "unicast" here. Looking at RFC 8562, it doesn't say anything about unicast (the string only occurs once there, in describing the base BFD). Would it be correct to delete "unicast", or change it to "data plane"? ### Section 3.2, too terse I found this description to be almost DISCUSS-level terse; it seriously impaired my ability to understand what is otherwise a clear document. A straightforward way to fix this would be to follow the usual convention of explaining every field, even if it's by reference. Looking at RFC 7212 Section 3, for instance, the authors are much more generous in the level of detail supplied -- there's a clear overview of the message structure, followed by field-level descriptions. But if that's seen as too verbose, another approach might be to at least annotate your diagram to indicate that the first three rows are per RFC 5586, the fourth row is per RFC 5880, and the final three rows are per RFC 7212. Another small fix might be to break up and restructure the big paragraph, which mixes justification (which the WG discussions might have needed but future implementors probably won't care about) with specification. Something like this: NEW: In some environments, the overhead of extra IP/UDP encapsulations may be considered burdensome, making the use of more compact G-ACh encapsulation attractive. Also, the validation of the IP/UDP encapsulation of a BFD Control packet in a p2mp BFD session may fail because of a problem related to neither the MPLS label stack nor to BFD. Avoiding unnecessary encapsulation of p2mp BFD over an MPLS LSP improves the accuracy of the correlation of the detected failure and defect in MPLS LSP. If a BFD Control packet in PW-ACH encapsulation (without IP/UDP Headers) is to be used in ACH, an implementation would not be able to verify the identity of the MultipointHead and, as a result, will not properly demultiplex BFD packets. Hence, a new channel type value is needed. ^^^ all that is justification, just reordered from what you had. You might even consider making it a different subsection so that implementors can more easily skim over it. That lets the meat of the section stand alone without distraction: Non-IP encapsulation for multipoint BFD over p2mp MPLS LSP (shown in Figure 1) MUST use Generic Associated Channel (G-ACh) Label (GAL) (see [RFC5586]) at the bottom of the label stack followed by an Associated Channel Header (ACH). The Channel Type field in ACH MUST be set to Multipoint BFD Session (TBA1) value (Section 7). To provide the identity of the MultipointHead for the particular multipoint BFD session, a Source Address TLV, as defined in Section 4.1 [RFC7212], MUST immediately follow a BFD Control message. The use of other TLVs defined in Section 4 of [RFC7212] is outside the scope of this document. ^^^ by the way, I guess other TLVs defined anywhere else are also outside the scope, so IMO it would be better to say, The use of other TLVs is outside the scope of this document. ### Section 4.2, BGP-BFD The BGP-BFD Attribute [RFC9026] MAY be used to bootstrap multipoint BFD session on a tail. There's no such attribute. I guess you meant the (BGP) BFD Discriminator Attribute. (There's also a minor grammar error, should be "a multipoint BFD session".) While we're talking about it, two other things -- - I guess you made the reference to RFC 9026 informative and not normative because this is an optional function? I think it's still normative because to implement this optional function the reader MUST read and understand RFC 9026. (An example of a truly informative reference would be something like "other means of bootstrapping multipoint BFD sessions, such as RFC 9026, are beyond the scope of this document.") - Since RFC 9026's scope is wider than just bootstrapping multipoint BFD sessions, I think it would be desirable to reference the relevant section. I think all the necessary procedure is in Section 3.1.6, is that right? If so, then perhaps something like, NEW: The BFD Discriminator Attribute MAY be used to bootstrap a multipoint BFD session on a tail, following the format and procedures given in Section 3.1.6 of [RFC9026]. ### Section 5, of? [RFC8562] defined how the BFD Demand mode can be used in multipoint networks. When applied in MPLS, procedures specified in [RFC8562] allow an egress LSR to detect a failure of the part of the MPLS p2mp LSP from the ingress LSR. What other part of the LSP is there, other than the part from the ingress LSR? Are you trying to say that the egress LSR doesn't detect failures on other branches (that don't include the egress LSR)? If so I think the sentence would be clearer if you added "... to that egress LSR" to the end. (Or you could just end the sentence after the word "failure", I think it would be clear enough in context and the sentence is non-normative.) |
2025-01-07
|
09 | John Scudder | Ballot comment text updated for John Scudder |
2025-01-07
|
09 | John Scudder | [Ballot comment] Thanks for this document, which I found straightforward to review with one exception, noted below. ### Section 1, unicast? [RFC8562] … [Ballot comment] Thanks for this document, which I found straightforward to review with one exception, noted below. ### Section 1, unicast? [RFC8562] defines a method of using Bidirectional Detection (BFD) [RFC5880] to monitor and detect unicast failures between the sender (head) and one or more receivers (tails) in multipoint or multicast networks. I don't understand the use of the word "unicast" here. Looking at RFC 8562, it doesn't say anything about unicast (the string only occurs once there, in describing the base BFD). Would it be correct to delete "unicast", or change it to "data plane"? ### Section 3.2, too terse I found this description to be almost DISCUSS-level terse; it seriously impaired my ability to understand what is otherwise a clear document. A straightforward way to fix this would be to follow the usual convention of explaining every field, even if it's by reference. Looking at RFC 7212 Section 3, for instance, the authors are much more generous in the level of detail supplied -- there's a clear overview of the message structure, followed by field-level descriptions. But if that's seen as too verbose, another approach might be to at least annotate your diagram to indicate that the first three rows are per RFC 5586, the fourth row is per RFC 5880, and the final three rows are per RFC 7212. Another small fix might be to break up and restructure the big paragraph, which mixes justification (which the WG discussions might have needed but future implementors probably won't care about) with specification. Something like this: NEW: In some environments, the overhead of extra IP/UDP encapsulations may be considered burdensome, making the use of more compact G-ACh encapsulation attractive. Also, the validation of the IP/UDP encapsulation of a BFD Control packet in a p2mp BFD session may fail because of a problem related to neither the MPLS label stack nor to BFD. Avoiding unnecessary encapsulation of p2mp BFD over an MPLS LSP improves the accuracy of the correlation of the detected failure and defect in MPLS LSP. If a BFD Control packet in PW-ACH encapsulation (without IP/UDP Headers) is to be used in ACH, an implementation would not be able to verify the identity of the MultipointHead and, as a result, will not properly demultiplex BFD packets. Hence, a new channel type value is needed. ^^^ all that is justification, just reordered from what you had. You might even consider making it a different subsection so that implementors can more easily skim over it. That lets the meat of the section stand alone without distraction: Non-IP encapsulation for multipoint BFD over p2mp MPLS LSP (shown in Figure 1) MUST use Generic Associated Channel (G-ACh) Label (GAL) (see [RFC5586]) at the bottom of the label stack followed by an Associated Channel Header (ACH). The Channel Type field in ACH MUST be set to Multipoint BFD Session (TBA1) value (Section 7). To provide the identity of the MultipointHead for the particular multipoint BFD session, a Source Address TLV, as defined in Section 4.1 [RFC7212], MUST immediately follow a BFD Control message. The use of other TLVs defined in Section 4 of [RFC7212] is outside the scope of this document. ^^^ by the way, I guess other TLVs defined anywhere else are also outside the scope, so IMO it would be better to say, The use of other TLVs is outside the scope of this document. ### Section 4.2, BGP-BFD The BGP-BFD Attribute [RFC9026] MAY be used to bootstrap multipoint BFD session on a tail. There's no such attribute. I guess you meant the (BGP) BFD Discriminator Attribute. (There's also a minor grammar error, should be "a multipoint BFD session".) While we're talking about it, two other things -- - I guess you made the reference to RFC 9026 informative and not normative because this is an optional function? I think it's still normative because to implement this optional function the reader MUST read and understand RFC 9026. (An example of a truly informative reference would be something like "other means of bootstrapping multipoint BFD sessions, such as RFC 9026, are beyond the scope of this document.") - Since RFC 9026's scope is wider than just bootstrapping multipoint BFD sessions, I think it would be desirable to reference the relevant section. I think all the necessary procedure is in Section 3.1.6, is that right? If so, then perhaps something like, NEW: The BFD Discriminator Attribute MAY be used to bootstrap a multipoint BFD session on a tail, following the format and procedures given in Section 3.1.6 of [RFC9026]. |
2025-01-07
|
09 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2025-01-07
|
09 | Mahesh Jethanandani | [Ballot comment] Thanks for addressing my DISCUSS and COMMENT. |
2025-01-07
|
09 | Mahesh Jethanandani | [Ballot Position Update] Position for Mahesh Jethanandani has been changed to No Objection from Discuss |
2025-01-07
|
09 | Gunter Van de Velde | [Ballot comment] Thanks for addressing my DISCUSS observation. I do still support the DISCUSS from Eric |
2025-01-07
|
09 | Gunter Van de Velde | [Ballot Position Update] Position for Gunter Van de Velde has been changed to No Objection from Discuss |
2025-01-06
|
09 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2025-01-06
|
09 | Orie Steele | [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele |
2025-01-06
|
09 | Paul Wouters | [Ballot comment] Note the document uses ":::1/128" in two places instead of "::1/128". |
2025-01-06
|
09 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2025-01-06
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2025-01-06
|
09 | Greg Mirsky | New version available: draft-ietf-mpls-p2mp-bfd-09.txt |
2025-01-06
|
09 | Greg Mirsky | New version accepted (logged-in submitter: Greg Mirsky) |
2025-01-06
|
09 | Greg Mirsky | Uploaded new revision |
2025-01-06
|
08 | Gunter Van de Velde | [Ballot discuss] # Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-p2mp-bfd-08 # I support the DISCUSS from Eric regarding usage of ::1/128 loopback address … [Ballot discuss] # Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-p2mp-bfd-08 # I support the DISCUSS from Eric regarding usage of ::1/128 loopback address # For the remainder i have a single DISCUSS that will be easy to resolve #DISCUSS #======= In the abstract it is mentioned that the IPv4 mapped IPv6 addresses are discouraged, but i did not find in the document explicitly explained why it is discouraged? Can this be outlined in a short explicit paragraph? G/ |
2025-01-06
|
08 | Gunter Van de Velde | Ballot discuss text updated for Gunter Van de Velde |
2025-01-06
|
08 | Gunter Van de Velde | [Ballot discuss] # Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-p2mp-bfd-08 # I support the DISCUSS from Eric regarding usage of ::1/128 loopback address … [Ballot discuss] # Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-p2mp-bfd-08 # I support the DISCUSS from Eric regarding usage of ::1/128 loopback address # For the remainder i have a single DISCUSS that will be easy to resolve #DISCUSS #======= In the abstract it is mentioned that the IPv4 mapped IPv6 addresses are discouraged, but i did not find in the document explicitly documented why it is discouraged? Can this be explained in a short paragraph? G/ |
2025-01-06
|
08 | Gunter Van de Velde | [Ballot Position Update] New position, Discuss, has been recorded for Gunter Van de Velde |
2025-01-06
|
08 | Éric Vyncke | [Ballot discuss] # Éric Vyncke, INT AD, comments for draft-ietf-mpls-p2mp-bfd-08 CC @evyncke Thank you for the work put into this document. Please find below one … [Ballot discuss] # Éric Vyncke, INT AD, comments for draft-ietf-mpls-p2mp-bfd-08 CC @evyncke Thank you for the work put into this document. Please find below one blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Nicolai Leymann for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ### Section 3.1 Happy to stand corrected, but I read section 3.1 as IP packets are sent outside of a node on a real (p2mp) link with a destination address of ::1/128. If confirmed, then this is an apparent violation of section 2.5.3 of RFC 4291 (even if sent over MPLS). I understand that this violation started already in RFC 8562, and I have no obvious solution to propose except using a link-local mcast address, e.g., ff02::2/128 (all link routers). |
2025-01-06
|
08 | Éric Vyncke | [Ballot comment] ## COMMENTS (non-blocking) ### Abstract and Section 1 s/recommends the use of *an* IPv6 loopback address/recommends the use of *the* IPv6 loopback address/ … [Ballot comment] ## COMMENTS (non-blocking) ### Abstract and Section 1 s/recommends the use of *an* IPv6 loopback address/recommends the use of *the* IPv6 loopback address/ ### Section 2.1 Suggest adding a reference (or a definition) of `G-ACh`. ### Section 3.1 Please use section 5 of RFC 5952 for `0:0:0:0:0:FFFF:7F00/104`. ### Section 3.2 In figure 1, some fields have a length that is specified and others have no length... Is it on purpose ? Even if the reader could guess, what are the expected sender/receiver behavior for the reserved fields ? ## NITS (non-blocking / cosmetic) ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-) |
2025-01-06
|
08 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
2025-01-04
|
08 | Mahesh Jethanandani | [Ballot discuss] Hear, hear! My DISCUSS should be easy to resolve. Section 3.1, paragraph 2 > * [RFC4291] defines a single IPv6 … [Ballot discuss] Hear, hear! My DISCUSS should be easy to resolve. Section 3.1, paragraph 2 > * [RFC4291] defines a single IPv6 loopback address. Hence, for > IPv6, the IPv6 loopback address ::1/128 SHOULD be used. Why a SHOULD and not a MUST? When a document uses a SHOULD instead of MUST, it almost always raises a DISCUSS point of what happens if an implementation decides not to follow the SHOULD. |
2025-01-04
|
08 | Mahesh Jethanandani | [Ballot comment] "Abstract", paragraph 1 > This document describes procedures for using Bidirectional Forwarding > Detection (BFD) for multipoint networks to detect data … [Ballot comment] "Abstract", paragraph 1 > This document describes procedures for using Bidirectional Forwarding > Detection (BFD) for multipoint networks to detect data plane failures > in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) > Label Switched Paths (LSPs) and Segment Routing (SR) point-to- > multipoint policies with SR-MPLS data plane. First of all, thanks to Bo Wu for providing an OPSDIR review. The thread mentions revision -09, but I do not see such a version in the datatracker. The latest version in the data tracker is still -08. ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 3.1, paragraph 2 > in the MPLS label stack or payload. Thus this specification further clarifies > ^^^^ A comma may be missing after the conjunctive/linking adverb "Thus". |
2025-01-04
|
08 | Mahesh Jethanandani | [Ballot Position Update] New position, Discuss, has been recorded for Mahesh Jethanandani |
2025-01-02
|
08 | Bo Wu | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Bo Wu. Sent review to list. |
2025-01-01
|
08 | Deb Cooley | [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley |
2024-12-27
|
08 | Carlos Pignataro | Request for Last Call review by OPSDIR is assigned to Bo Wu |
2024-12-16
|
08 | Darren Dukes | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Darren Dukes. Sent review to list. Submission of review completed at an earlier date. |
2024-12-16
|
08 | Darren Dukes | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Darren Dukes. |
2024-12-13
|
08 | Chris Lonvick | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. Sent review to list. |
2024-12-11
|
08 | Cindy Morgan | Placed on agenda for telechat - 2025-01-09 |
2024-12-11
|
08 | Jim Guichard | Ballot has been issued |
2024-12-11
|
08 | Jim Guichard | [Ballot Position Update] New position, Yes, has been recorded for Jim Guichard |
2024-12-11
|
08 | Jim Guichard | Created "Approve" ballot |
2024-12-11
|
08 | Jim Guichard | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2024-12-11
|
08 | Jim Guichard | Ballot writeup was changed |
2024-12-10
|
08 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-12-09
|
08 | David Dong | IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-mpls-p2mp-bfd-08. If any part of this review is inaccurate, please let us know. IANA understands that, upon … IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-mpls-p2mp-bfd-08. If any part of this review is inaccurate, please let us know. IANA understands that, upon approval of this document, there is a single action which we must complete. In the MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types) registry in the Generic Associated Channel (G-ACh) Parameters registry group located at: https://www.iana.org/assignments/g-ach-parameters/ a single new registration will be made as follows: Value: [ TBD-at-Registration ] Description: Multipoint BFD Session Reference: [ RFC-to-be ] We understand that this is the only action required to be completed upon approval of this document. NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2024-12-09
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2024-12-07
|
08 | Meral Shirazipour | Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour. Sent review to list. |
2024-12-01
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2024-11-27
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2024-11-26
|
08 | Daniam Henriques | Request for Last Call review by RTGDIR is assigned to Darren Dukes |
2024-11-26
|
08 | Liz Flynn | IANA Review state changed to IANA - Review Needed |
2024-11-26
|
08 | Liz Flynn | The following Last Call announcement was sent out (ends 2024-12-10): From: The IESG To: IETF-Announce CC: draft-ietf-mpls-p2mp-bfd@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, mpls@ietf.org, n.leymann@telekom.de … The following Last Call announcement was sent out (ends 2024-12-10): From: The IESG To: IETF-Announce CC: draft-ietf-mpls-p2mp-bfd@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, mpls@ietf.org, n.leymann@telekom.de Reply-To: last-call@ietf.org Sender: Subject: Last Call: (BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2024-12-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths (LSPs) and Segment Routing (SR) point-to- multipoint policies with SR-MPLS data plane. Furthermore, this document also updates RFC 8562 and recommends the use of an IPv6 loopback address (:::1/128) and discourages the use of an IPv4 loopback address mapped to IPv6. It also describes the applicability of LSP Ping, as in-band, and the control plane, as out-band, solutions to bootstrap a BFD session. It also describes the behavior of the active tail for head notification. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-p2mp-bfd/ No IPR declarations have been submitted directly on this I-D. |
2024-11-26
|
08 | Liz Flynn | IESG state changed to In Last Call from Last Call Requested |
2024-11-26
|
08 | Jim Guichard | Requested Last Call review by RTGDIR |
2024-11-26
|
08 | Jim Guichard | Requested Last Call review by OPSDIR |
2024-11-26
|
08 | Jim Guichard | Requested Last Call review by SECDIR |
2024-11-26
|
08 | Jim Guichard | Last call was requested |
2024-11-26
|
08 | Jim Guichard | Last call announcement was generated |
2024-11-26
|
08 | Jim Guichard | Ballot approval text was generated |
2024-11-26
|
08 | Jim Guichard | Ballot writeup was generated |
2024-11-26
|
08 | Jim Guichard | IESG state changed to Last Call Requested from AD Evaluation |
2024-11-26
|
08 | Jim Guichard | AD review found no substantive comments. Moving to IETF LC. |
2024-11-25
|
08 | Jim Guichard | IESG state changed to AD Evaluation from Publication Requested |
2024-11-01
|
08 | Nicolai Leymann | ## Document History 1 - Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did … ## Document History 1 - Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? During Working Group Last Call the document received sufficient support and a few (minor) comments. 2 - Was there controversy about particular points, or were there decisions where the consensus was particularly rough? Based on the feedback from the RTGDIR Last Call Review there was a fair amount discussion around congestion implications. The comments were addressed by updating the document. 3 - Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) None (see above). 4 - For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? There is no direct report regarding an existing implementation but it was stated that there are plans for implementations using the draft/RFC. 5 - Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. None needed. 6 - Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A. 7 - If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? N/A. 8 - Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. N/A. ### Document Shepherd Checks 9 - Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10 - Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? None. 11 - What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard. This state attribute is also reflected in the Datatracker. 12 - Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][8]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes (there are no IPRs for this document): https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-p2mp-bfd 13 - Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front pageis greater than five, please provide a justification. Yes (number of authors on the front page is three). 14 - Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) No issues found by I-D nits and review: Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 15 - Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No. 16 - List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? None. 17 - Are there any normative downward references (see [RFC3967][9] and [BCP97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. No. 18 - Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No. Only RFCs are referenced. 19 - Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No. 20 - Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The IANA is requested to allocate a value from its MPLS Generalized Associated Channel (G-ACh) registry. 21 - List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. None. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2024-11-01
|
08 | Nicolai Leymann | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2024-11-01
|
08 | Nicolai Leymann | IESG state changed to Publication Requested from I-D Exists |
2024-11-01
|
08 | (System) | Changed action holders to Jim Guichard (IESG state changed) |
2024-11-01
|
08 | Nicolai Leymann | Responsible AD changed to Jim Guichard |
2024-11-01
|
08 | Nicolai Leymann | Document is now in IESG state Publication Requested |
2024-11-01
|
08 | Nicolai Leymann | Changed consensus to Yes from Unknown |
2024-11-01
|
08 | Nicolai Leymann | Intended Status changed to Proposed Standard from None |
2024-08-26
|
08 | Greg Mirsky | New version available: draft-ietf-mpls-p2mp-bfd-08.txt |
2024-08-26
|
08 | Greg Mirsky | New version accepted (logged-in submitter: Greg Mirsky) |
2024-08-26
|
08 | Greg Mirsky | Uploaded new revision |
2024-08-20
|
07 | Nicolai Leymann | ## Document History 1 - Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did … ## Document History 1 - Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? During Working Group Last Call the document received sufficient support and a few (minor) comments. 2 - Was there controversy about particular points, or were there decisions where the consensus was particularly rough? Based on the feedback from the RTGDIR Last Call Review there was a fair amount discussion around congestion implications. The comments were addressed by updating the document. 3 - Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) None (see above). 4 - For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? There is no direct report regarding an existing implementation but it was stated that there are plans for implementations using the draft/RFC. 5 - Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. None needed. 6 - Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A. 7 - If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? N/A. 8 - Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. N/A. ### Document Shepherd Checks 9 - Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10 - Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? None. 11 - What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed Standard. This state attribute is also reflected in the Datatracker. 12 - Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][8]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes (there are no IPRs for this document): https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-p2mp-bfd 13 - Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front pageis greater than five, please provide a justification. Yes (number of authors on the front page is three). 14 - Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) No issues found by I-D nits and review: Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 15 - Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No. 16 - List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? None. 17 - Are there any normative downward references (see [RFC3967][9] and [BCP97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. No. 18 - Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No. Only RFCs are referenced. 19 - Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No. 20 - Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The IANA is requested to allocate a value from its MPLS Generalized Associated Channel (G-ACh) registry. 21 - List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. None. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2024-07-18
|
07 | Nicolai Leymann | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2024-07-18
|
07 | Nicolai Leymann | IETF WG state changed to In WG Last Call from WG Document |
2024-03-02
|
07 | Greg Mirsky | New version available: draft-ietf-mpls-p2mp-bfd-07.txt |
2024-03-02
|
07 | Greg Mirsky | New version accepted (logged-in submitter: Greg Mirsky) |
2024-03-02
|
07 | Greg Mirsky | Uploaded new revision |
2024-02-22
|
06 | Joel Halpern | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Joel Halpern. Sent review to list. Submission of review completed at an earlier date. |
2024-02-22
|
06 | Joel Halpern | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Joel Halpern. |
2024-02-22
|
06 | Daniam Henriques | Request for Last Call review by RTGDIR is assigned to Joel Halpern |
2024-02-21
|
06 | Nicolai Leymann | Requested Last Call review by RTGDIR |
2023-12-15
|
06 | Greg Mirsky | New version available: draft-ietf-mpls-p2mp-bfd-06.txt |
2023-12-15
|
06 | Greg Mirsky | New version accepted (logged-in submitter: Greg Mirsky) |
2023-12-15
|
06 | Greg Mirsky | Uploaded new revision |
2023-06-21
|
05 | Loa Andersson | Notification list changed to n.leymann@telekom.de because the document shepherd was set |
2023-06-21
|
05 | Loa Andersson | Document shepherd changed to Nicolai Leymann |
2023-06-19
|
05 | Greg Mirsky | New version available: draft-ietf-mpls-p2mp-bfd-05.txt |
2023-06-19
|
05 | Greg Mirsky | New version accepted (logged-in submitter: Greg Mirsky) |
2023-06-19
|
05 | Greg Mirsky | Uploaded new revision |
2022-12-22
|
04 | Greg Mirsky | New version available: draft-ietf-mpls-p2mp-bfd-04.txt |
2022-12-22
|
04 | Greg Mirsky | New version accepted (logged-in submitter: Greg Mirsky) |
2022-12-22
|
04 | Greg Mirsky | Uploaded new revision |
2022-12-07
|
03 | Greg Mirsky | New version available: draft-ietf-mpls-p2mp-bfd-03.txt |
2022-12-07
|
03 | Greg Mirsky | New version accepted (logged-in submitter: Greg Mirsky) |
2022-12-07
|
03 | Greg Mirsky | Uploaded new revision |
2022-08-18
|
02 | Greg Mirsky | New version available: draft-ietf-mpls-p2mp-bfd-02.txt |
2022-08-18
|
02 | Greg Mirsky | New version accepted (logged-in submitter: Greg Mirsky) |
2022-08-18
|
02 | Greg Mirsky | Uploaded new revision |
2022-08-14
|
01 | (System) | Document has expired |
2022-02-10
|
01 | Greg Mirsky | New version available: draft-ietf-mpls-p2mp-bfd-01.txt |
2022-02-10
|
01 | (System) | New version accepted (logged-in submitter: Greg Mirsky) |
2022-02-10
|
01 | Greg Mirsky | Uploaded new revision |
2022-02-10
|
00 | Loa Andersson | This document now replaces draft-mirsky-mpls-p2mp-bfd instead of None |
2022-02-10
|
00 | Greg Mirsky | New version available: draft-ietf-mpls-p2mp-bfd-00.txt |
2022-02-10
|
00 | (System) | WG -00 approved |
2022-02-09
|
00 | Greg Mirsky | Set submitter to "Greg Mirsky ", replaces to draft-mirsky-mpls-p2mp-bfd and sent approval email to group chairs: mpls-chairs@ietf.org |
2022-02-09
|
00 | Greg Mirsky | Uploaded new revision |