Hello authors,
This is a friendly reminder that we await answers to the questions below and
your review of the document before continuing with the publication process.
Please let us know if we can be of assistance as you complete your review. We
look forward to hearing from you.
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)
> -->
>
>
> 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)
>
> 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 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.
> -->
>
>
> 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.
> -->
>
>
> 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.
> -->
>
>
> 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.
> -->
>
>
> 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.
> -->
>
>
> 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.
> -->
>
>
> 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.
> -->
>
>
> 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.
> -->
>
>
> 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.
> -->
>
>
> 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];
> -->
>
>
> 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];
> -->
>
>
> 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].
> -->
>
>
> 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.
> -->
>
>
> 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:
> -->
>
>
> 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.
> -->
>
>
> 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.
> -->
>
>
> 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).
> -->
>
>
> 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?
> -->
>
>
> 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)
>
>
> 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
>
>
> c) We have updated "out-band" to "out-of-band" (two instances). Let us know
> any
> objections.
>
>
> 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)
> -->
>
>
> 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.
>
> 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)
> -->
>
>
> 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
> -->
>
>
> 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
>
> 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
>
> --------------------------------------
> RFC9780 (draft-ietf-mpls-p2mp-bfd-11)
>
> Title : Bidirectional Forwarding Detection (BFD) for Multipoint
> Networks over Point-to-Multi-Point MPLS Label Switched Path (LSP)
> Author(s) : G. Mirsky, G. Mishra, D. Eastlake 3rd
> WG Chair(s) : Tarek Saad, Tony Li, Adrian Farrel
>
> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
