Hi Rebecca
I reviewed the documents and am good with all the updates.
Kind Regards
Gyan
On Wed, May 14, 2025 at 12:48 AM Rebecca VanRheenen <
rvanrhee...@staff.rfc-editor.org> wrote:
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_styleguide_part2_-23inclusive-5Flanguage&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=0YTwolTzgM4A0o1_Rx8ZGvr8LJ-MSIn5f1ociq8B728&e=
> >
> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_faq_&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=bWxoDCOpUVG3BL7hITKHd9C1FO9Y2xVRMm7ZJA4k-Y4&e=
> ).
> >
> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__trustee.ietf.org_license-2Dinfo&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=6_9m59mE-JF5gcjs1y6ntOId2oU8lWhIl7h52-vGQRY&e=
> ).
> >
> > * 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://urldefense.proofpoint.com/v2/url?u=https-3A__authors.ietf.org_rfcxml-2Dvocabulary&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=sp6LoLEzXULoR9wIZBjv-Yu9YaX0wZVRgbM02yAsHFI&e=
> >.
> >
> > * 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://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_ietf-2Dannounce_yb6lpIGh-2D4Q9l2USxIAe6P8O4Zc&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=OgpMnI528RzuGvrm96Hgegu6gQVi2TTvMAuV1KA_wwA&e=
> >
> > * The archive itself:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_auth48archive_&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=g0AG9Xiuwa_bofHrMRy0SELCOcx16q1fpkHI9tvvkrQ&e=
> >
> > * 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=wADd8XD2iogcR0kFeyO5Cj6PAfWEE2APynuirHT4gw8&e=
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=r9LF3E0YIOPdLRGyrlNosI0Tliz8lfS4W5fm43qQmvg&e=
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780.pdf&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=Wsis9RsCjs9vczih6kOyOhD92ZUJKyoyRxwOX9JRJCQ&e=
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780.txt&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=qqyxkTyiz9Ezx8zO7_A3QkynrTh_kDxqWSEBol0JXL0&e=
> >
> > Diff file of the text:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=7Qtu9pOc50rhWo6JMY0voDRoD4WTDOQ1GnZaXmXyVaM&e=
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Drfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=UB2QQjNdKmYGRGFtgbrSpQctutG7oDFRSRNXmOdUIE8&e=
> (side by side)
> >
> > Alt-diff of the text (allows you to more easily view changes
> > where text has been deleted or moved):
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Dalt-2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=jAB0BVRPJ9IrYPO27EpZNVFDvNLU-H65hoJVuuYDLjo&e=
> >
> > Diff of the XML:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9780-2Dxmldiff1.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=87aNMgZiXXCNhIDbPUQuMCztccKEeBNlIhsZ5WNOzCI&e=
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_auth48_rfc9780&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=N3BN4MbSwbGOc69AWNiXebynGYSo8PiReGCL7rnLHn28J89PfD0Ea_J6-410i0Vh&s=SJOYZxHPGRrLcTCIP2XQjwXi-eZGXponMC_HamoEiJA&e=
> >
> > 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
