Hi Greg, Thank you for your quick response. We have noted your approval on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9780>.
Thank you, RFC Editor/sg > On May 20, 2025, at 9:21 AM, Greg Mirsky <gregimir...@gmail.com> wrote: > > Hi Sandy, > Thank you for your help in improving this document. I approve all the updates. > > Regards, > Greg > > On Tue, May 20, 2025, 08:54 Sandy Ginoza <sgin...@staff.rfc-editor.org> wrote: > Greetings Authors, > > We have updated the document to use “address block” consistently and posted > the files here: > > https://www.rfc-editor.org/authors/rfc9780.txt > https://www.rfc-editor.org/authors/rfc9780.pdf > https://www.rfc-editor.org/authors/rfc9780.html > https://www.rfc-editor.org/authors/rfc9780.xml > > Diffs highlighting the most recent updates only: > https://www.rfc-editor.org/authors/rfc9780-lastdiff.html > https://www.rfc-editor.org/authors/rfc9780-lastrfcdiff.html (side by side) > > AUTH48 diffs: > https://www.rfc-editor.org/authors/rfc9780-auth48diff.html > https://www.rfc-editor.org/authors/rfc9780-auth48rfcdiff.html (side by > side) > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9780-diff.html > https://www.rfc-editor.org/authors/rfc9780-rfcdiff.html (side by side) > > > Donald, with this update, we believe you approve the RFC for publication. We > have noted your approval on the AUTH48 page > <https://www.rfc-editor.org/auth48/rfc9780>. > > > Greg and Gyan, please let us know if any further updates are needed. We await > your approval before continuing with publication. > > Thank you > RFC Editor/sg > > > > > On May 19, 2025, at 9:16 AM, Donald Eastlake <d3e...@gmail.com> wrote: > > > > Hi Rebecca, > > > > I agree with Greg below on "range" -> "address block". With that minor > > change, I approve publication of this draft. > > > > Thanks, > > Donald > > =============================== > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 2386 Panoramic Circle, Apopka, FL 32703 USA > > d3e...@gmail.com > > > > On Sat, May 17, 2025 at 6:26 PM Greg Mirsky <gregimir...@gmail.com> wrote: > >> > >> Hi Rebecca, > >> Thank you for your careful updates, which significantly improved the > >> document. My follow-up note below is tagged GIM2>>. > >> > >> Best regards, > >> Greg > >> > >> On Fri, May 16, 2025 at 8:50 PM Rebecca VanRheenen > >> <rvanrhee...@staff.rfc-editor.org> wrote: > >>> > >>> Hi Greg and Donald, > >>> > >>> Thank you for the replies! We have updated the document per Greg’s reply. > >>> Donald, thank you for confirming your agreement with Greg's responses. > >>> > >>> We believe all questions have been addressed except for the followup > >>> question below. The other followup comments sent 2025-05-15 were > >>> addressed in Greg’s email (i.e., inclusive language and the sentence in > >>> Section 3). Are any further changes needed per the following? > >>> > >>>>>> d) Would either of the following read more clearly? Or is the current > >>>>>> okay? > >>>>>> > >>>>>> Current: > >>>>>> the Dummy IPv6 Prefix range 100:0:0:1::/64 > >>>>>> > >>>>>> Perhaps ("address block" instead of "range"): > >>>>>> the Dummy IPv6 Prefix address block 100:0:0:1::/64 > >>>>>> > >>>>>> Or ("address block" and parentheses): > >>>>>> the Dummy IPv6 Prefix address block (100:0:0:1::/64) > >>>> > >>>> I don't think parenthesis are needed but "address block" is good. > >>> > >>> “range” is used a few other times in the document aside from the context > >>> of "Dummy IPv6 Prefix range 100:0:0:1::/64”. Should those instances of > >>> “range” also be updated to “address block”? Or are these okay? > >> > >> GIM2>> I agree with you, please update s/range/address block/ throughout > >> the document to make it consistent. > >>> > >>> > >>> > >>> — FILES (please refresh) — > >>> > >>> Updated XML file: > >>> https://www.rfc-editor.org/authors/rfc9780.xml > >>> > >>> Updated output files: > >>> https://www.rfc-editor.org/authors/rfc9780.txt > >>> https://www.rfc-editor.org/authors/rfc9780.pdf > >>> https://www.rfc-editor.org/authors/rfc9780.html > >>> > >>> Diff file showing all changes made during AUTH48: > >>> https://www.rfc-editor.org/authors/rfc9780-auth48diff.html > >>> https://www.rfc-editor.org/authors/rfc9780-auth48rfcdiff.html (side by > >>> side) > >>> > >>> Diff files showing all changes: > >>> https://www.rfc-editor.org/authors/rfc9780-diff.html > >>> https://www.rfc-editor.org/authors/rfc9780-rfcdiff.html (side by side) > >>> https://www.rfc-editor.org/authors/rfc9780-alt-diff.html (diff showing > >>> changes where text is moved or deleted) > >>> > >>> For the AUTH48 status of this document, please see: > >>> https://www.rfc-editor.org/auth48/rfc9780 > >>> > >>> Thank you, > >>> > >>> RFC Editor/rv > >>> > >>> > >>> > >>>> On May 15, 2025, at 5:19 PM, Donald Eastlake <d3e...@gmail.com> wrote: > >>>> > >>>> Hi Rebecca, > >>>> > >>>> I agree with all of Greg's answers below including leaving "dummy" > >>>> unchanged and replacing the occurrences of "range" with "address > >>>> block". > >>>> > >>>> Thanks, > >>>> Donald > >>>> =============================== > >>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >>>> 2386 Panoramic Circle, Apopka, FL 32703 USA > >>>> d3e...@gmail.com > >>>> > >>>> On Thu, May 15, 2025 at 6:19 PM Greg Mirsky <gregimir...@gmail.com> > >>>> wrote: > >>>>> > >>>>> Rebecca, > >>>>> thank you for your thoughtful proposals helping in improving this > >>>>> document. > >>>>> Please find my responses to your questions below tagged GIM>>. > >>>>> > >>>>> Regards, > >>>>> Greg > >>>>> > >>>>> On Wed, May 14, 2025 at 7:48 PM Donald Eastlake <d3e...@gmail.com> > >>>>> wrote: > >>>>>> > >>>>>> Hi Rebecca, > >>>>>> > >>>>>> Sorry for the delayed response. > >>>>>> > >>>>>> On Wed, May 14, 2025 at 12:48 AM Rebecca VanRheenen > >>>>>> <rvanrhee...@staff.rfc-editor.org> wrote: > >>>>>>> > >>>>>>> Hello authors, > >>>>>>> > >>>>>>> This is a friendly reminder ... > >>>>>>> > >>>>>>> Thank you, > >>>>>>> RFC Editor/rv > >>>>>>> > >>>>>>>> On May 5, 2025, at 3:06 PM, rfc-edi...@rfc-editor.org wrote: > >>>>>>>> > >>>>>>>> Authors, > >>>>>>>> > >>>>>>>> While reviewing this document during AUTH48, please resolve (as > >>>>>>>> necessary) the following questions, which are also in the XML file. > >>>>>>>> > >>>>>>>> 1) <!-- [rfced] We made the following changes to the document title: > >>>>>>>> 1) updated > >>>>>>>> "Multi-Point" to "Multipoint" and 2) updated "Label Switched Path > >>>>>>>> (LSP)" > >>>>>>>> to "Label Switched Paths (LSPs)" (plural). Let us know any concerns. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Bidirectional Forwarding Detection (BFD) for Multipoint Networks over > >>>>>>>> Point-to-Multi-Point MPLS Label Switched Path (LSP) > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> Bidirectional Forwarding Detection (BFD) for Multipoint Networks over > >>>>>>>> Point-to-Multipoint MPLS Label Switched Paths (LSPs) > >>>>>>>> --> > >>>>>> > >>>>>> OK. > >>>>> > >>>>> GIM>> Agree with the updated version > >>>>>> > >>>>>> > >>>>>>>> 2) <!-- [rfced] Please review the following sentences in the > >>>>>>>> abstract and > >>>>>>>> introduction to ensure that they align with the document title and > >>>>>>>> the > >>>>>>>> rest of the document. These similar sentences mention SR P2MP > >>>>>>>> policies > >>>>>>>> with an SR-MPLS data plane, which are not mentioned in the document > >>>>>>>> title. In addition, we only see SR and SR-MPLS mentioned in one > >>>>>>>> sentence > >>>>>>>> in Section 4.1 (and in the Terminology section). Are any updates > >>>>>>>> needed? > >>>>>>>> > >>>>>>>> Document Title: > >>>>>>>> Bidirectional Forwarding Detection (BFD) for Multipoint Networks over > >>>>>>>> Point-to-Multipoint MPLS Label Switched Paths (LSPs) > >>>>>> > >>>>>> I think that title is OK. > >>>>> > >>>>> GIM>> We didn't elaborate on SR-MPLS because there are no differences > >>>>> between it and IP/MPLS in the applicability of p2mp BFD. The MPLS and > >>>>> SPRING WGs acknowledged that. Thus, I believe that there's no need to > >>>>> add any informational text in this regard. > >>>>>> > >>>>>> > >>>>>>>> Abstract: > >>>>>>>> This document describes procedures for using Bidirectional Forwarding > >>>>>>>> Detection (BFD) for multipoint networks to detect data plane failures > >>>>>>>> in MPLS point-to-multipoint Label Switched Paths (LSPs) and Segment > >>>>>>>> Routing (SR) point-to-multipoint policies with an SR over MPLS (SR- > >>>>>>>> MPLS) data plane. > >>>>>>>> > >>>>>>>> Introduction: > >>>>>>>> This document describes procedures for using such modes of the BFD > >>>>>>>> protocol 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 an > >>>>>>>> SR over MPLS (SR-MPLS) data plane. > >>>>>>>> --> > >>>>>>>> > >>>>>>>> > >>>>>>>> 3) <!-- [rfced] FYI - We updated "and recommends...and discourages" > >>>>>>>> to "by > >>>>>>>> recommending...and discouraging" (we also made a similar change in > >>>>>>>> the > >>>>>>>> introduction). Please review and let us know any concerns. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Furthermore, this document also updates RFC 8562 and recommends the > >>>>>>>> use of an IPv6 address from the Dummy IPv6 range TBA2/64 > >>>>>>>> (Section 7.1) and discourages the use of an IPv4 loopback address > >>>>>>>> mapped to IPv6. > >>>>>>>> > >>>>>>>> Updated: > >>>>>>>> Furthermore, this document updates RFC 8562 by recommending the > >>>>>>>> use of an IPv6 address from the Dummy IPv6 Prefix range > >>>>>>>> 100:0:0:1::/64 > >>>>>>>> and discouraging the use of an IPv4 loopback address > >>>>>>>> mapped to IPv6. > >>>>>>>> --> > >>>>>> > >>>>>> OK. > >>>>> > >>>>> GIM>> I agree with the proposed update; thank you > >>>>>> > >>>>>> > >>>>>>>> 4) <!-- [rfced] How may we update this sentence to improve > >>>>>>>> readability? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> It also describes the applicability of LSP Ping, as in-band, and the > >>>>>>>> control plane, as out-band, solutions to bootstrap a BFD session. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> This document also describes the applicability of LSP Ping (as an > >>>>>>>> in-band > >>>>>>>> solution) and the control plane (as an out-of-band solution) to > >>>>>>>> bootstrap > >>>>>>>> a BFD session. > >>>>>>>> --> > >>>>>> > >>>>>> I think your rewording is good. > >>>>> > >>>>> GIM>> I concur with Donald. > >>>>>> > >>>>>> > >>>>>>>> 5) <!-- [rfced] Please review the following sentences. The first > >>>>>>>> sentence (from > >>>>>>>> the abstract) mentions both in-band and out-of-band solutions, but > >>>>>>>> the > >>>>>>>> sentence (from the introduction) only mentions out-of-band > >>>>>>>> solutions. Should these be aligned? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> It also describes the applicability of LSP Ping, as in-band, and the > >>>>>>>> control plane, as out-band, solutions to bootstrap a BFD session. > >>>>>>>> ... > >>>>>>>> The document also describes the applicability of out-band solutions > >>>>>>>> to bootstrap a BFD session in this environment. > >>>>>>>> --> > >>>>>> > >>>>>> Seems like a good idea to add a few words to the introduction sentence > >>>>>> so > >>>>>> > >>>>>> The document also describes the applicability of LSP Ping and > >>>>>> out-band solutions to bootstrap a BFD session in this environment > >>>>> > >>>>> GIM>> I agree with your suggestion adding reference to the use of LSP > >>>>> Ping as in-band bootstrapping mechanism. It could be helpful to a > >>>>> reader if the update also notes that LSP Ping serves as an in-band > >>>>> mechanism. Perhaps update can be as follows: > >>>>> NEW TEXT: > >>>>> The document also describes the applicability of LSP Ping, as in-band, > >>>>> and > >>>>> out-band solutions to bootstrap a BFD session in this environment > >>>>>> > >>>>>> > >>>>>>>> 6) <!-- [rfced] Please review "to select destination IPv6 addresses > >>>>>>>> for" > >>>>>>>> here. Would updating as follows make this text more clear? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Hence, IANA is requested > >>>>>>>> to allocate TBA2/64 as a new Dummy IPv6 Prefix (Section 7.1) to > >>>>>>>> select destination IPv6 addresses for IP/UDP encapsulation of > >>>>>>>> management, control, and OAM packets. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> Hence, IANA has > >>>>>>>> allocated 100:0:0:1::/64 as a new Dummy IPv6 Prefix (Section 7.1) for > >>>>>>>> destination IPv6 addresses used for IP/UDP encapsulation of > >>>>>>>> management, control, and Operations, Administration, and Maintenance > >>>>>>>> (OAM) packets. > >>>>> > >>>>> GIM>> I agree with that update and expansion of the OAM acronym on the > >>>>> first use. > >>>>>> > >>>>>>>> --> > >>>>>> > >>>>>> I really don't like that "a, b, and c, d, and e" construct. It's > >>>>>> confusing. Regardless of whatever the general rule is about spelling > >>>>>> out acronyms on first occurrence and then giving the acronym in > >>>>>> parenthesis, this would read better as below. Otherwise fine. > >>>>>> > >>>>>> management, control, and OAM (Operations, Administration, and > >>>>>> Maintenance) packets. > >>>>>> > >>>>>>>> 7) <!-- [rfced] We see both of the following in Section 1: > >>>>>>>> > >>>>>>>> address::ffff:127.0.0.1/128 > >>>>>>>> ::ffff:127.0.0.1/128 > >>>>>>>> > >>>>>>>> Should "address::ffff:127.0.0.1/128" be updated as follows? > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> Historically, an IPv6-mapped IPv4 loopback range > >>>>>>>> address::ffff:127.0.0.1/128 was mandated, although functionally, an > >>>>>>>> IPv6 address from that range is not analogous to its IPv4 > >>>>>>>> counterpart. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> Historically, an address in the IPv6-mapped IPv4 loopback range > >>>>>>>> ::ffff:127.0.0.1/128 was mandated, although functionally, an > >>>>>>>> IPv6 address from that range is not analogous to its IPv4 > >>>>>>>> counterpart. > >>>>>> > >>>>>>>> --> > >>>>>> > >>>>>> I think that is a good change. > >>>>> > >>>>> GIM>> I agree, thank you > >>>>>> > >>>>>> > >>>>>>>> 8) <!-- [rfced] To improve readability, we split this long sentence > >>>>>>>> into two > >>>>>>>> sentences. Would it be helpful to further update to use > >>>>>>>> "::ffff:127.0.0.1/128 range" instead of "IPv6-mapped IPv4 loopback > >>>>>>>> range > >>>>>>>> address" in the second sentence? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Thus, this > >>>>>>>> document also updates [RFC8562] and recommends the use of an IPv6 > >>>>>>>> address from the Dummy IPv6 Prefix range TBA2/64 (Section 7.1) while > >>>>>>>> acknowledging that an address from ::ffff:127.0.0.1/128 range might > >>>>>>>> be used by existing implementations, discourages the use of the > >>>>>>>> IPv6-mapped IPv4 loopback range address. > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> Thus, this > >>>>>>>> document updates [RFC8562] by recommending the use of an IPv6 address > >>>>>>>> from the Dummy IPv6 Prefix range 100:0:0:1::/64 (Section 7.1) while > >>>>>>>> acknowledging that an address from the ::ffff:127.0.0.1/128 range > >>>>>>>> might be used by existing implementations. This document discourages > >>>>>>>> the use of an address in the IPv6-mapped IPv4 loopback range. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> Thus, this > >>>>>>>> document updates [RFC8562] by recommending the use of an IPv6 address > >>>>>>>> from the Dummy IPv6 Prefix range 100:0:0:1::/64 (Section 7.1) while > >>>>>>>> acknowledging that an address from the ::ffff:127.0.0.1/128 range > >>>>>>>> might be used by existing implementations. This document discourages > >>>>>>>> the use of an address from the ::ffff:127.0.0.1/128 range. > >>>>>>>> --> > >>>>>> > >>>>>> I think your current text is best. > >>>>> > >>>>> GIM>> I think that we can keep the current version of the text. > >>>>>> > >>>>>> > >>>>>>>> 9) <!-- [rfced] We do not see "demultiplex" in Section 3.1. Please > >>>>>>>> review and let > >>>>>>>> us know if any updates are needed. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> If the BFD Control packet is encapsulated in IP/UDP, then > >>>>>>>> the source IP address MUST be used to demultiplex the received BFD > >>>>>>>> Control packet as described in Section 3.1. > >>>>>>>> --> > >>>>>> > >>>>>> I do not think Section 3.1 needs any further change. It is about > >>>>>> encapsulation while demultiplexing is about handling on receipt. > >>>>> > >>>>> GIM>> I agree with Donald that there is no apparent need to update > >>>>> Section 3.1 of this draft. Instead, we should update the reference to > >>>>> point to Section 5.7 of RFC 8562. Hence, the text reads as follows: > >>>>> NEW TEXT: > >>>>> If the BFD Control packet is encapsulated in IP/UDP, then > >>>>> the source IP address MUST be used to demultiplex the received BFD > >>>>> Control packet as described in Section 5.7 of [RFC8562]. > >>>>>> > >>>>>> > >>>>>>>> 10) <!-- [rfced] Should the introductory text include the first part > >>>>>>>> of the > >>>>>>>> indented text here? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Thus, this > >>>>>>>> specification further clarifies that: > >>>>>>>> > >>>>>>>> if multiple alternative paths for the given p2mp LSP Forwarding > >>>>>>>> Equivalence Class (FEC) exist, the MultipointHead SHOULD use the > >>>>>>>> Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise > >>>>>>>> those particular alternative paths; > >>>>>>>> > >>>>>>>> or the MultipointHead MAY use the UDP port number to possibly > >>>>>>>> exercise those particular alternate paths. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> This > >>>>>>>> specification further clarifies the following if multiple > >>>>>>>> alternative paths > >>>>>>>> for the given P2MP LSP Forwarding Equivalence Class (FEC) exist: > >>>>>>>> > >>>>>>>> * The MultipointHead SHOULD use the Entropy Label [RFC6790] used > >>>>>>>> for LSP > >>>>>>>> Ping [RFC8029] to exercise those particular alternative paths; or > >>>>>>>> > >>>>>>>> * The MultipointHead MAY use the UDP port number to possibly > >>>>>>>> exercise those > >>>>>>>> particular alternate paths. > >>>>>>>> --> > >>>>>> > >>>>>> I don't think any material needs to be added to the Introduction. > >>>>> > >>>>> GIM>> I think that the update improves readability. I support the > >>>>> proposed version. > >>>>>> > >>>>>> > >>>>>>>> 11) <!-- [rfced] The following sentences appear twice in Section 3.2 > >>>>>>>> (as the > >>>>>>>> second paragraph and in the third paragraph). Which should be > >>>>>>>> removed? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> 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. > >>>>>>>> --> > >>>>>> > >>>>>> I think the 2nd paragraph should be deleted. > >>>>> > >>>>> GIM>> I agree with removing the second paragraph. > >>>>>> > >>>>>> > >>>>>>>> 12) <!-- [rfced] Would it be helpful to clarify "the top three > >>>>>>>> four-octet words" > >>>>>>>> here? Will readers understand what is defined in RFC 5586? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> * the top three four-octet words as defined in [RFC5586]; > >>>>>>>> --> > >>>>>> > >>>>>> I think it is OK as is. > >>>>> > >>>>> GIM>> I agree with Donald, this terminology is accepted in computing. > >>>>>> > >>>>>> > >>>>>>>> 13) <!-- [rfced] We do not see mention of "BFD Control Message" in > >>>>>>>> [RFC5880]. > >>>>>>>> Please review. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> * the BFD Control Message field is as defined in [RFC5880]; > >>>>>>>> --> > >>>>>> > >>>>>> I believe the problem is that RFC 5880 refers to it as a BFD Control > >>>>>> Packet rather than a BFD Control Message. Since it isn't really > >>>>>> referring to the entire packet on the wire, it seems to me that > >>>>>> Message is more correct. > >>>>>> > >>>>>> Perhaps the explanation below the figure should be: > >>>>>> > >>>>>> * The BFD Control Message field is as defined in [RFC5880] where it > >>>>>> is referred to as the BFD Control Packet. > >>>>> > >>>>> GIM>> A very good question, thank you. As Donald noted, "BFD Control > >>>>> packet" and "BFD Control message" are used interchangeably in documents > >>>>> and discussions. One solution could be to add a note to that in the > >>>>> Terminology section or replace all four occurrences of "BFD Control > >>>>> message" with "BFD Control packet". I can live with any solution, but > >>>>> the latter might be easier to apply. WDYT? > >>>>>> > >>>>>> > >>>>>>>> 14) <!-- [rfced] Should the two instances of "Target FEC TLV" here > >>>>>>>> be "Target FEC > >>>>>>>> Stack TLV"? We see "Target FEC Stack TLV" in RFC 6425. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> LSP Ping, as defined in [RFC6425], MAY be used to bootstrap > >>>>>>>> MultipointTail. If LSP Ping is used, it MUST include the Target FEC > >>>>>>>> TLV and the BFD Discriminator TLV defined in [RFC5884]. For the case > >>>>>>>> of p2mp MPLS LSP, the Target FEC TLV MUST use sub-TLVs defined in > >>>>>>>> Section 3.1 [RFC6425]. > >>>>>>>> --> > >>>>>> > >>>>>> I believe "Target FEC TLV" is just short for "Target FEC Stack TLV" > >>>>>> which is specified in RFC 8029 which is already a Normative > >>>>>> reference. I suggest: > >>>>>> > >>>>>> LSP Ping, as defined in [RFC6425], MAY be used to bootstrap > >>>>>> MultipointTail. If LSP Ping is used, it MUST include the Target FEC > >>>>>> Stack TLV [RFC8029] and the BFD Discriminator TLV [RFC5884]. For > >>>>>> the case of p2mp MPLS LSP, the Target FEC Stack TLV MUST use > >>>>>> sub-TLVs defined in Section 3.1 [RFC6425]. > >>>>> > >>>>> GIM>> I agree with the text proposed by Donald. > >>>>>> > >>>>>> > >>>>>>>> 15) <!-- [rfced] May we update the introductory text to use "MUST" > >>>>>>>> and remove > >>>>>>>> "MUST" from each bullet? Or do you prefer the current? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> A MultipointTail that receives an LSP Ping that includes the BFD > >>>>>>>> Discriminator TLV: > >>>>>>>> > >>>>>>>> * MUST validate the LSP Ping; > >>>>>>>> > >>>>>>>> * MUST associate the received BFD Discriminator value with the p2mp > >>>>>>>> LSP; > >>>>>>>> > >>>>>>>> * MUST create a p2mp BFD session and set bfd.SessionType = > >>>>>>>> MultipointTail as described in [RFC8562]; > >>>>>>>> > >>>>>>>> * MUST use the source IP address of LSP Ping, the value of BFD > >>>>>>>> Discriminator from the BFD Discriminator TLV, and the identity of > >>>>>>>> the p2mp LSP to properly demultiplex BFD sessions. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> A MultipointTail that receives an LSP Ping that includes the BFD > >>>>>>>> Discriminator TLV MUST do the following: > >>>>>>>> > >>>>>>>> * validate the LSP Ping; > >>>>>>>> > >>>>>>>> * associate the received BFD Discriminator value with the P2MP > >>>>>>>> LSP; > >>>>>>>> > >>>>>>>> * create a P2MP BFD session and set bfd.SessionType = > >>>>>>>> MultipointTail as described in [RFC8562]; and > >>>>>>>> > >>>>>>>> * use the source IP address of the LSP Ping, the value of BFD > >>>>>>>> Discriminator from the BFD Discriminator TLV, and the identity of > >>>>>>>> the P2MP LSP to properly demultiplex BFD sessions. > >>>>>>>> --> > >>>>>> > >>>>>> OK with your change. > >>>>> > >>>>> GIM>> I concur with Donald and support the updated text. > >>>>>> > >>>>>> > >>>>>>>> 16) <!-- [rfced] The second bulleted list in Section 5 is prefaced > >>>>>>>> with the > >>>>>>>> following text. However, it looks like only the first four bullets > >>>>>>>> detail > >>>>>>>> settings. Should the last two bullets be regular paragraphs rather > >>>>>>>> than > >>>>>>>> part of the list? Or should this introductory text be updated? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Upon detecting the failure of the p2mp MPLS LSP, an egress LSR sends > >>>>>>>> BFD Control packet with the following settings: > >>>>>>>> --> > >>>>>> > >>>>>> I think the last two bullet items can be regular paragraphs. > >>>>> > >>>>> GIM>> I agree with your proposal, it improves the readability. > >>>>>> > >>>>>> > >>>>>>>> 17) <!-- [rfced] What does "it" refer to here? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> * these BFD Control packets are transmitted at the rate of one per > >>>>>>>> second until either it receives a control packet valid for this > >>>>>>>> BFD session with the Final (F) bit set from the ingress LSR or the > >>>>>>>> defect condition clears. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> * These BFD Control packets are transmitted at the rate of one per > >>>>>>>> second until either 1) the egress LSA receives a control packet > >>>>>>>> from the ingress LSR > >>>>>>>> that is valid for this BFD session and has the Final (F) bit set > >>>>>>>> or 2) the > >>>>>>>> defect condition clears. > >>>>>>>> --> > >>>>>> > >>>>>> I agree with your suggested change. > >>>>> > >>>>> GIM>> I concur with Donald and agree with the proposed update. > >>>>>> > >>>>>> > >>>>>>>> 18) <!-- [rfced] Please clarify "defined above" here. Is the intent > >>>>>>>> "as defined > >>>>>>>> above" (with "as"), "with the settings described above", or something > >>>>>>>> else? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> However, to improve the likelihood of > >>>>>>>> notifying the ingress LSR of the failure of the p2mp MPLS LSP, the > >>>>>>>> egress LSR SHOULD initially transmit three BFD Control packets > >>>>>>>> defined above in short succession. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> However, to improve the likelihood of > >>>>>>>> notifying the ingress LSR of the failure of the p2mp MPLS LSP, the > >>>>>>>> egress LSR SHOULD initially transmit three BFD Control packets > >>>>>>>> (as defined above) in short succession. > >>>>>>>> --> > >>>>>> > >>>>>> OK with your change. > >>>>> > >>>>> GIM>> Thank you for the proposed update, I agree with you. > >>>>>> > >>>>>> > >>>>>>>> 19) <!-- [rfced] FYI - We updated Table 2 to <dl> as the table was > >>>>>>>> too wide for > >>>>>>>> the txt output. Note that <dl> was used in other RFCs that have made > >>>>>>>> allocations in the "IANA IPv6 Special-Purpose Address Registry" > >>>>>>>> (e.g., > >>>>>>>> RFCs 9637, 9602, and 9374). > >>>>>>>> --> > >>>>>> > >>>>>> OK. > >>>>> > >>>>> GIM>> Thank you, agreed. > >>>>>> > >>>>>> > >>>>>>>> 20) <!-- [rfced] An informative reference is listed for the "IANA > >>>>>>>> IPv6 Special > >>>>>>>> Purpose Address Registry" in Section 7.1. Would you like to also add > >>>>>>>> an > >>>>>>>> informative reference for the "MPLS Generalized Associated Channel > >>>>>>>> (G-ACh) Types" registry in Section 7.2? > >>>>>>>> --> > >>>>>> > >>>>>> I think that is a good idea. > >>>>> > >>>>> GIM>> Great suggestion, thanks. > >>>>>> > >>>>>> > >>>>>>>> 21) <!-- [rfced] Terminology > >>>>>>>> > >>>>>>>> a) We see the following forms used in this document. Should "P2MP" > >>>>>>>> or "MPLS" > >>>>>>>> come first in this phrase? > >>>>>>>> > >>>>>>>> p2mp MPLS LSP > >>>>>>>> MPLS p2mp LSP > >>>>>>>> Point-to-Multipoint MPLS Label Switched Path (LSP) > >>>>>>>> MPLS point-to-multipoint Label Switched Paths (LSPs) > >>>>>> > >>>>>> I believe P2MP or Point-to-Multipoint should come first. > >>>>> > >>>>> GIM>> I agree with Donald. > >>>>>> > >>>>>> > >>>>>>>> b) Please review the instances of "echo" in the document and let us > >>>>>>>> know if > >>>>>>>> they should be capitalized or lowercased. > >>>>>>>> > >>>>>>>> MPLS echo reply > >>>>>>>> MPLS echo request > >>>>>>>> LSP Ping Echo request message > >>>>>> > >>>>>> Generally, echo should be the same case as "reply' or "request", that > >>>>>> is, in the above cases, lower case. > >>>>> > >>>>> GIM>> Lowercase is consistent with RFC 8029: > >>>>> It defines a probe message called an "MPLS > >>>>> echo request" and a response message called an "MPLS echo reply" for > >>>>> returning the result of the probe. > >>>>>> > >>>>>> > >>>>>>>> c) We have updated "out-band" to "out-of-band" (two instances). Let > >>>>>>>> us know any > >>>>>>>> objections. > >>>>>> > >>>>>> That seems good. > >>>>> > >>>>> GIM>> I agree with the update. > >>>>>> > >>>>>> > >>>>>>>> d) Would either of the following read more clearly? Or is the > >>>>>>>> current okay? > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> the Dummy IPv6 Prefix range 100:0:0:1::/64 > >>>>>>>> > >>>>>>>> Perhaps ("address block" instead of "range"): > >>>>>>>> the Dummy IPv6 Prefix address block 100:0:0:1::/64 > >>>>>>>> > >>>>>>>> Or ("address block" and parentheses): > >>>>>>>> the Dummy IPv6 Prefix address block (100:0:0:1::/64) > >>>>>> > >>>>>> I don't think parenthesis are needed but "address block" is good. > >>>>> > >>>>> GIM>> As Donald said, I support the first option. > >>>>>> > >>>>>> > >>>>>>>> --> > >>>>>>> > >>>>>>>> 22) <!-- [rfced] Abbreviations > >>>>>>>> > >>>>>>>> a) We updated "p2mp" (lowercase) to "P2MP" (caps). The capitalized > >>>>>>>> form is much > >>>>>>>> more common in published RFCs, including in RFCs 9026 and 6425, > >>>>>>>> which are > >>>>>>>> normatively referenced by this document. > >>>>>> > >>>>>> OK. > >>>>> > >>>>> GIM>>> Accepted > >>>>>> > >>>>>> > >>>>>>>> b) FYI - We have added expansions for the following abbreviations > >>>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > >>>>>>>> expansion in the document carefully to ensure correctness. > >>>>>>>> > >>>>>>>> Operations, Administration, and Maintenance (OAM) > >>>>>>>> Pseudowire (PW) > >>>>>> > >>>>>> OK. > >>>>> > >>>>> GIM>> Agree > >>>>>> > >>>>>> > >>>>>>>> --> > >>>>>>>> > >>>>>>>> 23) <!-- [rfced] Please review the "Inclusive Language" portion of > >>>>>>>> the online > >>>>>>>> Style Guide > >>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > >>>>>>>> and let us know if any changes are needed. Updates of this nature > >>>>>>>> typically > >>>>>>>> result in more precise language, which is helpful for readers. > >>>>>>>> > >>>>>>>> For example, please consider whether the following should be updated: > >>>>>>>> > >>>>>>>> Dummy > >>>>>> > >>>>>> I understand the problems with Dummy but it is hard to find another > >>>>>> word with the right connotations. The best I can do is suggest > >>>>>> replacing Dummy with Marker. > >>>>> > >>>>> GIM>> IANA registries of Special addresses already list address blocks > >>>>> that include Dummy in the title. IESG agreed to that name. > >>>>>> > >>>>>> > >>>>>>>> --> > >>>>>>>> > >>>>>>>> Thank you. > >>>>>>>> RFC Editor/rv > >>>>>>>> > >>>>>>>> On May 5, 2025, at 3:01 PM, rfc-edi...@rfc-editor.org wrote: > >>>>>>>> > >>>>>>>> *****IMPORTANT***** > >>>>>>>> > >>>>>>>> Updated 2025/05/05 > >>>>>>>> > >>>>>>>> RFC Author(s): > >>>>>>>> -------------- > >>>>>>>> > >>>>>>>> Instructions for Completing AUTH48 > >>>>>>>> > >>>>>>>> Your document has now entered AUTH48. Once it has been reviewed and > >>>>>>>> approved by you and all coauthors, it will be published as an RFC. > >>>>>>>> If an author is no longer available, there are several remedies > >>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). > >>>>>>>> > >>>>>>>> You and you coauthors are responsible for engaging other parties > >>>>>>>> (e.g., Contributors or Working Group) as necessary before providing > >>>>>>>> your approval. > >>>>>>>> > >>>>>>>> Planning your review > >>>>>>>> --------------------- > >>>>>>>> > >>>>>>>> Please review the following aspects of your document: > >>>>>>>> > >>>>>>>> * RFC Editor questions > >>>>>> > >>>>>> See above. > >>>>>> > >>>>>> Thanks, > >>>>>> Donald > >>>>>> =============================== > >>>>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >>>>>> 2386 Panoramic Circle, Apopka, FL 32703 USA > >>>>>> d3e...@gmail.com > >>>>>> > >>>>>>>> Please review and resolve any questions raised by the RFC Editor > >>>>>>>> that have been included in the XML file as comments marked as > >>>>>>>> follows: > >>>>>>>> > >>>>>>>> <!-- [rfced] ... --> > >>>>>>>> > >>>>>>>> These questions will also be sent in a subsequent email. > >>>>>>>> > >>>>>>>> * Changes submitted by coauthors > >>>>>>>> > >>>>>>>> Please ensure that you review any changes submitted by your > >>>>>>>> coauthors. We assume that if you do not speak up that you > >>>>>>>> agree to changes submitted by your coauthors. > >>>>>>>> > >>>>>>>> * Content > >>>>>>>> > >>>>>>>> Please review the full content of the document, as this cannot > >>>>>>>> change once the RFC is published. Please pay particular attention > >>>>>>>> to: > >>>>>>>> - IANA considerations updates (if applicable) > >>>>>>>> - contact information > >>>>>>>> - references > >>>>>>>> > >>>>>>>> * Copyright notices and legends > >>>>>>>> > >>>>>>>> Please review the copyright notice and legends as defined in > >>>>>>>> RFC 5378 and the Trust Legal Provisions > >>>>>>>> (TLP – https://trustee.ietf.org/license-info). > >>>>>>>> > >>>>>>>> * Semantic markup > >>>>>>>> > >>>>>>>> Please review the markup in the XML file to ensure that elements of > >>>>>>>> content are correctly tagged. For example, ensure that <sourcecode> > >>>>>>>> and <artwork> are set correctly. See details at > >>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. > >>>>>>>> > >>>>>>>> * Formatted output > >>>>>>>> > >>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the > >>>>>>>> formatted output, as generated from the markup in the XML file, is > >>>>>>>> reasonable. Please note that the TXT will have formatting > >>>>>>>> limitations compared to the PDF and HTML. > >>>>>>>> > >>>>>>>> > >>>>>>>> Submitting changes > >>>>>>>> ------------------ > >>>>>>>> > >>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as > >>>>>>>> all > >>>>>>>> the parties CCed on this message need to see your changes. The > >>>>>>>> parties > >>>>>>>> include: > >>>>>>>> > >>>>>>>> * your coauthors > >>>>>>>> > >>>>>>>> * rfc-edi...@rfc-editor.org (the RPC team) > >>>>>>>> > >>>>>>>> * other document participants, depending on the stream (e.g., > >>>>>>>> IETF Stream participants are your working group chairs, the > >>>>>>>> responsible ADs, and the document shepherd). > >>>>>>>> > >>>>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list > >>>>>>>> to preserve AUTH48 conversations; it is not an active discussion > >>>>>>>> list: > >>>>>>>> > >>>>>>>> * More info: > >>>>>>>> > >>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > >>>>>>>> > >>>>>>>> * The archive itself: > >>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >>>>>>>> > >>>>>>>> * Note: If only absolutely necessary, you may temporarily opt out > >>>>>>>> of the archiving of messages (e.g., to discuss a sensitive > >>>>>>>> matter). > >>>>>>>> If needed, please add a note at the top of the message that you > >>>>>>>> have dropped the address. When the discussion is concluded, > >>>>>>>> auth48archive@rfc-editor.org will be re-added to the CC list and > >>>>>>>> its addition will be noted at the top of the message. > >>>>>>>> > >>>>>>>> You may submit your changes in one of two ways: > >>>>>>>> > >>>>>>>> An update to the provided XML file > >>>>>>>> — OR — > >>>>>>>> An explicit list of changes in this format > >>>>>>>> > >>>>>>>> Section # (or indicate Global) > >>>>>>>> > >>>>>>>> OLD: > >>>>>>>> old text > >>>>>>>> > >>>>>>>> NEW: > >>>>>>>> new text > >>>>>>>> > >>>>>>>> You do not need to reply with both an updated XML file and an > >>>>>>>> explicit > >>>>>>>> list of changes, as either form is sufficient. > >>>>>>>> > >>>>>>>> We will ask a stream manager to review and approve any changes that > >>>>>>>> seem > >>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of > >>>>>>>> text, > >>>>>>>> and technical changes. Information about stream managers can be > >>>>>>>> found in > >>>>>>>> the FAQ. Editorial changes do not require approval from a stream > >>>>>>>> manager. > >>>>>>>> > >>>>>>>> > >>>>>>>> Approving for publication > >>>>>>>> -------------------------- > >>>>>>>> > >>>>>>>> To approve your RFC for publication, please reply to this email > >>>>>>>> stating > >>>>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, > >>>>>>>> as all the parties CCed on this message need to see your approval. > >>>>>>>> > >>>>>>>> > >>>>>>>> Files > >>>>>>>> ----- > >>>>>>>> > >>>>>>>> The files are available here: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9780.xml > >>>>>>>> https://www.rfc-editor.org/authors/rfc9780.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9780.pdf > >>>>>>>> https://www.rfc-editor.org/authors/rfc9780.txt > >>>>>>>> > >>>>>>>> Diff file of the text: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9780-diff.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9780-rfcdiff.html (side by > >>>>>>>> side) > >>>>>>>> > >>>>>>>> Alt-diff of the text (allows you to more easily view changes > >>>>>>>> where text has been deleted or moved): > >>>>>>>> https://www.rfc-editor.org/authors/rfc9780-alt-diff.html > >>>>>>>> > >>>>>>>> Diff of the XML: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9780-xmldiff1.html > >>>>>>>> > >>>>>>>> > >>>>>>>> Tracking progress > >>>>>>>> ----------------- > >>>>>>>> > >>>>>>>> The details of the AUTH48 status of your document are here: > >>>>>>>> https://www.rfc-editor.org/auth48/rfc9780 > >>>>>>>> > >>>>>>>> Please let us know if you have any questions. > >>>>>>>> > >>>>>>>> Thank you for your cooperation, > >>>>>>>> > >>>>>>>> RFC Editor > >>> > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
