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
