Hi Loa,
thank you for your thorough review and constructive comments; greatly appreciated. My apologies for the belated response. Please find my notes below tagged GIM>>. Attached is the new working version of the draft and the diff to highlight updates noted below and those that are intended to address the Alvaro's WGLC comments.
Regards,
Greg
On Fri, Dec 20, 2024 at 3:46 AM Loa Andersson <loa@xxxxx> wrote:
All,
Sorry I forgot to clean up the template at one point, the Summary should
say:
Summary:
I have some minor concerns about this document that I think should be
resolved before publication.
Overview:
The document describes the use of > BFD for monitoring individual
segment lists of candidate paths of an SR Policy. It documents the use
of various BFD modes and features such as BFD Demand mode, Seamless BFD,
and BFD Echo function with the BFD Control packet payload in an SR-MPLS
domain. The document also defines the use of LSP Ping for Segmen Routing
networks over the MPLS data plane [RFC8287] to bootstrap and control
path of a BFD session from the egress LER to the ingress LER using
Segment Routing segment list with MPLS data plane (SR-MPLS).
Then it should be followed by "Minor Issues" as below.
/Loa
Den 20/12/2024 kl. 12:31, skrev Loa Andersson via Datatracker:
> Reviewer: Loa Andersson
> Review result: Has Issues
>
> RTG-DIR LC review of draft-ietf-spring-bfd
> RTG-DIR Last Call review of draft-ietf-spring-bfd-12
>
> Routing Directorate Last Call Review Template
> To:
>
> rtg-ads@xxxxxxxx
> Cc:
>
> rtg-dir@xxxxxxxx;
> draft-ietf-spring-bfd.all@xxxxxxxx;
> spring@xxxxxxxx;
> last-call@xxxxxxxx;
> Subject:
>
> RtgDir Last Call review: draft-ietf-spring-bfd-12
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft. The
> Routing Directorate seeks to review all routing or routing-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing ADs.
> For more information about the Routing Directorate, please see
> https://wiki.ietf.org/en/group/rtg/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it would
> be helpful if you could consider them along with any other IETF Last Call
> comments that you receive, and strive to resolve them through discussion or by
> updating the draft.
>
> Document: draft-ietf-spring-bfd-12
> Reviewer: Loa Andersson
> Review Date: date
> IETF LC End Date: 2024-12-13
> Intended Status: Experimental
>
> Summary:
> Choose from this list...
>
> No issues found. This document is ready for publication.
> This document is basically ready for publication but has nits that should be
> considered prior to publication. I have some minor concerns about this document
> that I think should be resolved before publication. I have significant concerns
> about this document and recommend that the Routing ADs discuss these issues
> further with the authors. Comments: Please supply an overview of the draft
> quality and readability. Include anything else that you think will be helpful
> toward understanding your review. Overview The document describes the use of
> BFD for monitoring individual segment lists of candidate paths of an SR Policy.
> It documents the use of various BFD modes and features such as BFD Demand mode,
> Seamless BFD, and BFD Echo function with the BFD Control packet payload. in the
> SR-MPLS domain. The document also defines the use of LSP Ping for Segment
> Routing networks over the MPLS data plane [RFC8287] to bootstrap and control
> path of a BFD session from the egress LER to the ingress LER using Segment
> Routing segment list with MPLS data plane (SR-MPLS).
>
> Mailing list discussion
> The SPRING mailining list has been actvie discussing this WGLC. I had not read
> all the mails when I started my review, but has done so prior to finish it.
> There are some overlaps, and some differences between my comments and thise on
> the mailing list, for example ALvaro and I both have a comment on the use of
> the "expected" in the Abstract, I suggest a change and Alvaro to drop the enire
> sentence. While I prefer what I proposed, I have no problem living with what
> Alvaro proposes. This is true for almost all overlapping comments, I have made
> a note if I strongly prefer something I suggested.
>
Minor issues
IANA Considerations
I have a some concerns about the IANA
> Considerations. Ketan had almost the same concerns in a mail to the list, but
> the document has changed, so I go through.
>
> It is OK to allocate the new "Non-FEC Path TLV" the
> way you do.
>
> However you assign it from a range that require a response
> if the the TLV is not recognized, which is fine if that is
> what you want. If that is the case this need to be
> described in section 3.1.
GIM>> You are correct. The expectation (and the running experiment) is that the addressee that does not recognize Non-FEC Path TLV will respond with the "One or more of the TLVs was not understood " Return Code. Added the following text in Section 3.1:
NEW TEXT:
If the receiver of the
echo request doesn't recognize Non-FEC Path TLV, it MUST set the
Return Code in an echo reply to 2 ("One or more of the TLVs was not
understood").
>
> If youy think that it can be silently dropped if not
> recognized you should use range 49162-64507. Again you
> need to describe this in section 3.1.
> Table 1 should have a column listing if there are sub-TLV registries or not.
>
> +=======+==================+===============+============+
> | Value | TLV Name | Reference | Sub-TLV |
> | | | |registry |
> +=======+==================+===============+============|
> | TBD1 | Non-FEC Path TLV | This document | Non-FEC |
> | | | |Path sub-TLV|
> +-------+------------------+---------------+------------|
>
> Table 1: New Non-FEC Path TLV
> Since you assign a sub-TLV I prefer that you list it.
GIM>> Please let me know if I correctly followed you suggestion:
+=======+==================+===============+==================+
| Value | TLV Name | Reference | Sub-TLV Registry |
+=======+==================+===============+==================+
| TBD1 | Non-FEC Path TLV | This document | Path sub-TLV |
+-------+------------------+---------------+------------------+
Table 1: New Non-FEC Path TLV
>
> You create the Non-FEC Path sub-TLV registry almost correctly, but I think
> Table 2 should look like this:
>
> +=============+==============+===========================+
> | 0-16383 | Standards | This range is for sub-TLVs|
> | | Action | that require an error |
> | | | message if notrecognized. |
> | | | [RFC9041, Section 3.1 |
> +=============+==============+===========================+
> | 16384-31739 | RFC | This range is for sub-TLVs|
> | | Required | that require an error |
> | | | message if notrecognized. | | |
> | [RFC9041, Section 3.1 |
> +=============+==============+===========================+ | 31740-31743 |
> Experimental | Reserved, not to be | | | Use |
> assigned. | | | | This range is for
> sub-TLVs| | | | that require an error | |
> | | message if notrecognized. | | |
> | [RFC9041, Section 3.1 |
> +=============+==============+===========================+ | 31744-32767 |
> First Come | This range is for sub-TLVs| | | Use | that
> require an error | | | | message if notrecognized.
> | | | | [RFC9041, Section 3.1 |
> +=============+==============+===========================+ | 32768-49161 |
> Standards | This range is for sub-TLVs| | | Action | that
> that can be silently | | | | dropped if notrecognized.
> | +=============+==============+===========================+ | 49162-64507 |
> RFC | This range is for sub-TLVs| | | Required | that
> that can be silently | | | | dropped if notrecognized.
> | +=============+==============+===========================+ | 64508-64511
> | Experimental | Reserved, not to be | | | Use |
> assigned. | | | | This range is for
> sub-TLVs| | | | that that can be silently | |
> | | dropped if notrecognized. |
> +=============+==============+===========================+ | 64512-65535 |
> First Come | This range is for sub-TLVs| | | Use | that
> that can be silently | | | | dropped if notrecognized.
> | +=============+==============+===========================+ I.e. do it exactly
> as for other sub-TLV registries. If not you'll have to motivate this.
GIM>> Please let me know if updates of Table 2 capture your suggestions. I noticed that RFC 8126 among the allocation policies lists "First Come First Served" , and I used that. also, I noticed that for the Experimental Use you suggest a Reserved, not to be assigned. Is that because Section 4.2 of RFC 8126 notes that IANA does not tracks the use of values from the experimental range? Should I reference Section 4.2 in the Notes?
>
> Some questions:
>
> Experimental RFC needed
> In the "Note column" of the "Non-FEC Path sub-TLV registry" you "Specification
> Required", that registration policy is the widest we have, almost anything that
> we can imagine to be a "specification" is allowed. All documents from any SDO
> is liokely to pass that var. You scribble something on a napkin, take a photo
> of it and store somewhere where it is publicly retrievable, and you can make a
> case for "specification". Then we go to the "Note" field and there you say
> "Experimental RFC needed", so you limit our widest category down to a single
> type of document. Please not that "Experimental RFC needed" is not a
> registrtation policy. If you want it you have to describe it,
>
> Why is that? Isn't RFC do it like this? Isn't RFC Required" sufficicient?
GIM>> As noted above, Table 2 was updated according to your recommendation, including the for Experimental Use ranges. I couldn't figure out whether "Reserved, Not to be assigned" belongs - Registration Procedures column of Note.
>
> Populate new registries
> When you create a new registry you can populate if, the "TBDs" are not needed,
> there are no conflicts. IANA will review and do what you say. We let INA pick
> the values when there are a risk for conflict. Add a value instead of "TBD2".
GIM>> Thank you for the suggestion. Done.
>
> First Come, First Served
> Why did you remove FCFS? We had a long discussion on including it when we wrote
> RFC 9041.
GIM>> Thank you for pointing that out to me. The new Non-FEC Path sub-TLV registry now uses FCFS policy.
>
> Assignement conflicts
> For "Non-FEC Path sub-TLV registry" you first say that we have a small problem.
> You want to Reserve to values "0" and "65535". The glitch is that you first say
> that for "0" the registration policy is "Standard Tracks", and then yo try to
> "Reserve" it from and Experimental RFC. It shold not work.
>
> For "65535" you first say it "First Come, First Served" and then"Reserve", it
> can't be both. I think you can reserve "0" and "65535" and make the first
> Standard track range 1-16383, and the Private Use range 64512-65534. But I
> think yuo should get an opinion from IANA before you commit.
>
> Alternatively you could do as all other sub-TLV registries does, skip reserving
> 65535.
GIM>> I agree with the partition of the values you suggested for the Non-FEC Path sub-TLV registry.
>
> Assigment from the Return Code registry
> You are requesting that a Standard Track code point from the "Return Codes"
> registry. You can't do that from an Experimental RFC. I suggest that you ask
> for a value from the RFC Required range instead.
GIM>> Updated according to your recommendation.
>
> Nits:
>
> Nits are editorial or layout items. They are things that would ideally be
> resolved before publication to make the document more readable and may be
> raised now to save the RFC Editor's work. Usually a reviewer will not be
> looking for this type of issue but may find some in the course of their review.
> Please try to avoid raising esoteric questions about English usage. The RFC
> Editor will spot these, and it is not a wise use of time to discuss these
> things. If you find no nits, please leave this section out. Abstract SR-MPLS is
> not a wellknow abbreviation, so it need to expanded at first use. If it is used
> both in the Abstract and the document text I think it should be expanded twice.
> The Abstract is treated as something stand-alone.
>
> Terminology
> Consistency
> This is is inconsistence, sometimes there is a ":" between the abbreviation and
> expansion, sometime not. I prefer with the ":".
>
> SR-MPLS
> In the terminology section you expand SR-MPLS as:
>
> SR-MPLS Segment Routing with MPLS data plane
> The working group have told the RFC Editor to use:
>
> SR-MPLS Segment Routing over MPLS
> in the Abbreviation list. We should follow the abbreviation list.
GIM>> Updated per your suggestion.
>
> The terminology section kisses:
>
> LSR Label Switching Router
> which is used in setion 11.
GIM>> Changed to the expanded form.
>
> Section 2
> You correctly have a reference to RFC 8660, but the forwarding plane operation
> "NEXT" shows up a bit abrupt and if I undedrstand correctly it is explained in
> RFC 8402, could please add some text on what "NEXT" is and where to find the
> definition.
>
> In section 2 you have this paragraph:
>
> When LSP Ping is used to bootstrapping a BFD session for
> SR-MPLS segment list the FEC corresponding to the last
> segment to be associated with the BFD session MUST be
> as the very last sub-TLV in the Target FEC TLV.
> First, a "Target FEC" TLV does not exist. There is a "Target FEC Stack" TLV
> (TLV # 1)is that the TLV you mean?
>
> Second, the "Target FEC Stack" TLV shares sub-TLVs with the "Reverse-path
> Target FEC Stack" TLV and the "Reply Path" TLV, together there are in the order
> of 50 sub-TLVs defined. Then you say "last must be last", is that among all
> sub-TLVs, or just among those defined in this document.
GIM>> As a result of addressing WG LC Chair's comments, Section 2 changed. I hope that you agree with the updates and that they address your concerns.
>
> You also have this paragraph:
>
> Encapsulation of a BFD Control packet in Segment Routing
> network with MPLS data plane MUST follow Section 7
> [RFC5884] when the IP/UDP header used and MUST follow
> Section 3.4 [RFC6428] without IP/UDP header being used.
> I think this would be better:
>
> Encapsulation of a BFD Control packet in Segment Routing
> networks over a MPLS data plane MUST follow Section 7 of
> [RFC5884] when the IP/UDP is header used. The
> encapsulation MUST follow Section 3.4 of [RFC6428] when
> an IP/UDP header is not used.
GIM>> Thank you for the recommendation that improves the readability. Applied in the working version.
> Section 3
> I found the text hard to read, I think it could be improved. If you want I can
> do an attempt off-line.
GIM>> Thank you for your kind offer. Section 3 was updated to address Alavor's comments. I greatly appreciate your help in improving the new version in the attached copy of the working version of the draft.
>
> Section 3.1
> RFC 8029 gives the names of the LÖSP Ping messages as:
>
> MPLS echo request; and
> MPLS echo reply
> In section 3.1 you use "echo request" and "Echo Request", please align with RFC
> 8029.
GIM>> Thank you. Done throughout the document.
>
> Section 3.2
> Section 3.2 is unclear. You say:
>
> "...BFD Reverse Path TLV MAY use Target FEC sub-TLVs
> defined in [RFC8287]."
> Do you mean that it can use ALL the Target FEC Stack TLVs, or just the three
> sub-TLVs defined in RFC 8287? If the latter I think we should say:
>
> "...the BFD Reverse Path TLV MAY use the three Target FEC
> sub-TLVs defined in [RFC8287]."
> I also wonder about the "MAY", is there an alternative. maybe the is "may"?
GIM>> As the result of addressing WG Chair's comments Section 3.2 now reads as:
Target FEC sub-TLVs defined in [RFC8287] are applicable in SR domains
that are in the scope of [RFC8287].
Does the new text resolve your concern?
>
> Section 4
> s/can be following in SR-MPLS/can be followed in SR-MPLS
GIM>> Done.
>
> You say:
>
> "an ingress SR node bootstraps BFD session over SR-MPLS in Async BFD mode"
>
> RFC 5880 does not use "Async BFD mode", but uses "Asynchronous mode", I think
> we should follow RFC 5880.
GIM>> Fixed in two remaining occurences.
>
> You say:
>
> "it sends its BFD Control packet to the ingress SR node over the IP network
> with a Poll sequence"
>
> You might want to add a reference to RFC 5880 section 6.5.
GIM>> Thank you for the suggestion. Done.
>
> Section 5
> In your text is p2mp and multicast synoumous? I have a tendency to think of
> multicast as a application offered to "users" that they can join or leave,
> while p2mp is a service that a lower layer supply. I'm not dogmnatic about just
> wanna know how to understand your text.
GIM>> Thank you for another great question, Loa. I agree with your view of p2mp vs. multicast. The text refers to multicat in connection with a service and a distribution tree. In that section, p2mp is used as a synonym of Multipoint, and in P2MP SR Policy. Would you suggest an editorial update or a clarification?
>
> Section 6
> In section 6 you use "Echo-BFD", "Echo BFD". and "Echo BFD packets", RFC 5880
> talks about "BFD Echo packets", please align.
GIM>> Done.
>
> Section 10
> Security considerations are normally outside the scope of my competence, I'll
> be waiting for the SEC-DIR review of the document.
>
> I know from experience that the SEC-DIR does not like "no additional security
> risks".
>
> Grammar concerns
> I have a couple of comments that are grammatical in nature. Please take care
> with these comments. English is not my mother tongue, but I'm happy if you read
> and consider (even if you decide not to take what I suggest).
>
> MPLS Data Plane
> In the Abstract you talk about the MPLS Data Plane and say:
>
> Inm the 2nd sentence "It can be realized in the Multiprotocol Label Switching
> (MPLS) network without changing the data plane."
>
> I have the feeling that "without changing the data plane" can be understood
> that the entire data plane is swapped, maybe:
>
> s/without changing the data plane/without any changes to the data plane/
GIM>> I agree and updated accordingly.
>
> "Expected to"
> The second sentence in the Abstract says:
>
> "Bidirectional Forwarding Detection (BFD) is expected to monitor a segment
> list..."
>
> I have the feeling that "expectations" leave quite a bit of
> uncertainty. What about:
> s/(BFD) is expected to/(BFD) is used to/
GIM>> Abstract got significant re-work, and that wording now reads as:
This
document describes using Bidirectional Forwarding Detection (BFD) for
monitoring individual segment lists of candidate paths of an SR
Policy.
Please let me know if the readability improved.
>
> Language concerns
> I think there is a need to clean up the language in this document, but for
> easily understandle reasons I'm not the person to do this.
>
> I can point at some problems, for example I find that articles (the, a and an)
> are often missing. However, my English is not good enough.
>
>
>
--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
loa@xxxxx
loa.pi.nu.@xxxxxxxxx
SPRING Working Group G. Mirsky
Internet-Draft Ericsson
Intended status: Experimental J. Tantsura
Expires: 5 August 2025 NVIDIA
I. Varlashkin
Google
M. Chen
Huawei
J. Wenying
CMCC
1 February 2025
Bidirectional Forwarding Detection (BFD) in Segment Routing Networks
Using MPLS Dataplane
draft-ietf-spring-bfd-13
Abstract
The Segment Routing (SR) architecture leverages the paradigm of
source routing. It can be realized in the Multiprotocol Label
Switching (MPLS) network without any changes to the data plane. This
document describes using Bidirectional Forwarding Detection (BFD) for
monitoring individual segment lists of candidate paths of an SR
Policy. It documents the use of various BFD modes and features such
as BFD Demand mode, Seamless BFD, and BFD Echo function with the BFD
Control packet payload in the Segment Routing over MPLS domain.
Also, this document defines how to use Label Switched Path Ping to
bootstrap a BFD session, with optional control of selecting a segment
list in the reverse direction of the BFD session.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 August 2025.
Mirsky, et al. Expires 5 August 2025 [Page 1]
Internet-Draft BFD in SPRING MPLS February 2025
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Terminology and Abbreviations . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4
2. Initialization of a BFD Session Over a Segment List with MPLS
Data Plane . . . . . . . . . . . . . . . . . . . . . . . 4
3. Using BFD Reverse Path TLV over SR Policy's Segment List . . 4
3.1. Use of Non-FEC Path TLV . . . . . . . . . . . . . . . . . 5
3.1.1. SR Policy's Segment List sub-TLV . . . . . . . . . . 6
3.2. BFD Reverse Path TLV over SR Policy's Segment List with
Dynamic Control Plane . . . . . . . . . . . . . . . . . . 6
4. Applicability of BFD Demand Mode in SR-MPLS Domain . . . . . 6
5. Using BFD to Monitor Point-to-Multipoint SR Policy . . . . . 7
6. Use of BFD Echo in SR-MPLS . . . . . . . . . . . . . . . . . 8
7. Use of S-BFD in SR-MPLS . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 9
8.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 11
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. The Scope of the Experiment . . . . . . . . . . . . . . . . . 13
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
14.1. Normative References . . . . . . . . . . . . . . . . . . 13
14.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Mirsky, et al. Expires 5 August 2025 [Page 2]
Internet-Draft BFD in SPRING MPLS February 2025
1. Introduction
[RFC5880], [RFC5881], and [RFC5883] define the operation of the
Bidirectional Forwarding Detection (BFD) protocol between two systems
over IP networks. [RFC5884] and [RFC7726] set rules for using BFD
Asynchronous mode over point-to-point (p2p) Multiprotocol Label
Switching (MPLS) Label Switched Path (LSP). These latter standards
implicitly assume that the remote BFD system, which is at the egress
Label Edge Router (LER), will use the shortest path route to
periodically transmit its BFD Control messages regardless of the path
the BFD system at the ingress LER uses to send BFD Control packets
towards it.
[RFC9256] defines the SR Policy architecture. When analyzing the
applicability of a BFD-based mechanism for detecting network failures
in a Segment Routing domain, it is essential to identify the
monitored SR Policy elements.
This document describes the use of BFD for monitoring individual
segment lists of candidate paths of an SR Policy. It documents the
use of various BFD modes and features such as BFD Demand mode,
Seamless BFD, and BFD Echo function with the BFD Control packet
payload. in the Segment Routing over MPLS (SR-MPLS) domain. Also,
this document defines the use of LSP Ping for Segment Routing
networks over the MPLS data plane [RFC8287] to bootstrap and control
path of a BFD session from the egress LER to the ingress LER using
Segment Routing segment list with MPLS data plane (SR-MPLS).
1.1. Conventions
1.1.1. Terminology and Abbreviations
Throughout this document, references to ingress LER and egress LER
are used, respectively, as a shortened version of the "BFD system at
the ingress/egress LER".
BFD: Bidirectional Forwarding Detection
FEC: Forwarding Equivalence Class
MPLS: Multiprotocol Label Switching
SR-MPLS: Segment Routing over MPLS
LSP: Label Switched Path
LER: Label Edge Router
Mirsky, et al. Expires 5 August 2025 [Page 3]
Internet-Draft BFD in SPRING MPLS February 2025
p2p: Point-to-point
p2mp: Point-to-multipoint
SID: Segment Identifier
SR: Segment Routing
S-BFD: Seamless BFD
1.1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Initialization of a BFD Session Over a Segment List with MPLS Data
Plane
LSP Ping SHOULD be used to bootstrap the BFD sessions [RFC5884]
unless other means are available, e.g., using an extension to a
dynamic routing protocol as described in [RFC9026] and [RFC9186].
The procedures specified in [RFC8287] for using LSP Ping with an MPLS
data plane MUST be used.
To support a BFD session for each candidate path of the given SR
Policy, ingress and egress LERs MUST conform to the procedures
specified in Section 2 of [RFC7726].
Encapsulation of a BFD Control packet in Segment Routing network with
MPLS data plane MUST follow Section 7 [RFC5884] when the IP/UDP
header is used. The encapsulation MUST follow Section 3.4 [RFC6428]
if the IP/UDP header is not used.
3. Using BFD Reverse Path TLV over SR Policy's Segment List
For BFD over MPLS LSP case, per [RFC5884], egress LER MUST send BFD
Control packet to the ingress LER using one of two encapsulations -
IP/UDP or MPLS. For the case of BFD over a p2p SR-MPLS segment list,
the egress LER MUST send BDF Control Packets to the ingress LER
either using an IP encapsulation as specified in Section 5 of
[RFC5883], or encapsulated in an MPLS label stack as specified in
Section 7 of [RFC5884].
Mirsky, et al. Expires 5 August 2025 [Page 4]
Internet-Draft BFD in SPRING MPLS February 2025
The mechanisms mentioned above don't ensure that both directions of
the BFD session use co-routed paths, which may contribute to false
positive defect notifications [RFC9612]. To instruct the egress BFD
system to use an explicit path for the BFD Control Packets associated
with a particular BFD session, the procedures defined in [RFC9612]
MUST be used.
3.1. Use of Non-FEC Path TLV
For the case of MPLS data plane, Segment Routing Architecture
[RFC8402] explains that "a segment is encoded as an MPLS label. An
ordered list of segments is encoded as a stack of labels."
This document defines a new optional Non-FEC Path TLV. The format of
the Non-FEC Path TLV is presented in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non-FEC Path TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Non-FEC Path ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Non-FEC Path TLV Format
Non-FEC Path TLV Type field is two octets in length and has a value
of TBD1 (to be assigned by IANA as requested in Section 8.1).
The Length field is two octets long and defines the length in octets
of the Non-FEC Path field.
The Non-FEC Path field MUST contain at most one sub-TLV. Any Non-FEC
Path sub-TLV (defined in this document or to be defined in the
future) for Non-FEC Path TLV type may be used in this field. If no
sub-TLV has been found in the Non-FEC Path TLV, the egress LER MUST
revert to using the reverse path selected based on its local policy.
If there is more than one sub-TLV, then the Return Code in an MPLS
echo reply MUST be set to value TBD3 "Too Many TLVs Detected" (to be
assigned by IANA as requested in Table 4). If the receiver of the
MPLS echo request doesn't recognize Non-FEC Path TLV, it MUST set the
Return Code in an MPLS echo reply to 2 ("One or more of the TLVs was
not understood").
Mirsky, et al. Expires 5 August 2025 [Page 5]
Internet-Draft BFD in SPRING MPLS February 2025
3.1.1. SR Policy's Segment List sub-TLV
This document defines the SR Policy's Segment List sub-TLV that MAY
be used with the Non-FEC Path TLV. The format of the sub-TLV is
presented in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment List sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Entry 1 (Top of Stack) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Entry 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Entry N (Bottom of Stack) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SR Policy's Segment List sub-TLV
The SR Policy's Segment List sub-TLV Type is two octets in length,
and has a value of 1 (to be assigned by IANA as requested in
Section 8.1).
The Length field is two octets long and defines the length in octets
of Label Stack Entries listed in that sub-TLV.
The Label Stack Entry field is four octets long and is the label
stack entry as defined in Section 2.1 of [RFC3032]. Label Stack
Entries MUST be in network order. The egress LER MUST use the Label
fields of the Label Stack Entry field as label stack for BFD Control
packets for the BFD session identified by the source IP address of
the MPLS LSP Ping packet and the value in the BFD Discriminator TLV.
3.2. BFD Reverse Path TLV over SR Policy's Segment List with Dynamic
Control Plane
Target FEC Stack sub-TLVs defined in [RFC8287] are applicable in SR
domains that are in the scope of [RFC8287].
4. Applicability of BFD Demand Mode in SR-MPLS Domain
Sections 6.6 and 6.18.4 of [RFC5880] define how Demand mode of BFD
can be used to monitor uni-directional MPLS LSP. Similar procedures
can be followed in SR-MPLS to monitor uni-directional SR tunnels:
Mirsky, et al. Expires 5 August 2025 [Page 6]
Internet-Draft BFD in SPRING MPLS February 2025
* an ingress SR node bootstraps the BFD session over SR-MPLS in
Asynchronous BFD mode;
* once the BFD session is Up, the ingress SR node switches the
egress LER into the Demand mode by setting D field in BFD Control
packet it transmits;
* if the egress LER detects the failure of the BFD session, it sends
its BFD Control packet to the ingress SR node over the IP network
with a Poll sequence (Section 6.5 of [RFC5880]);
* if the ingress SR node receives a BFD Control packet from the
remote node in a Demand mode with Poll sequence and Diag field
indicating the failure, the ingress SR node transmits BFD Control
packet with Final over IP and switches the BFD over SR-MPLS back
into Asynchronous mode, sending BFD Control packets one per
second.
5. Using BFD to Monitor Point-to-Multipoint SR Policy
Segment Routing Replication for Multipoint Service Delivery [RFC9524]
defined variants of SR Policy to deliver point-to-multipoint (p2mp)
services. For the given segment list of an p2mp SR Policy, BFD for
Multipoint Networks [RFC8562] can be used if, for example, leaves
have an alternative source of the multicast service flow to select.
In such a scenario, a leaf may switch to using the alternative flow
after p2mp BFD detects the failure in the working multicast path.
For scenarios where it is required for the root to monitor the state
of the multicast tree BFD Multipoint Active Tails [RFC8563] can be
used. The root may use the detection of the failure of the multicast
tree to the particular leaf to restore the path for that leaf or re-
instantiate the whole multicast tree.
An essential part of using p2mp BFD is the bootstrapping the BFD
session at all the leaves. The root, acting as the MultipointHead,
MAY use LSP Ping [I-D.ietf-mpls-p2mp-bfd] and
[I-D.ietf-pim-p2mp-policy-ping] with the BFD Discriminator TLV.
Also, the BGP-BFD Attribute [RFC9026] MAY be used to bootstrap a
multipoint BFD session on a tail. Furthermore, other extensions to
routing protocols or the management plane could be defined in the
future to serve similar purposes, but such work is out of the scope
of this document.
Mirsky, et al. Expires 5 August 2025 [Page 7]
Internet-Draft BFD in SPRING MPLS February 2025
6. Use of BFD Echo in SR-MPLS
BFD Echo [RFC5880] can be used to monitor a segment list of the
particular SR Policy between the local and the remote BFD peers. As
defined in [RFC5880], the remote BFD system does not process the
payload of a BFD Echo packet. Thus, the local system demultiplexes
the BFD Echo packet. matches it to the appropriate BFD session, and
detects missing BFD Echo packets. A BFD Control packet MAY be used
as the payload of the BFD Echo packet. This specification defines
the use of the BFD Echo function in the SR-MPLS network with BFD
Control packet as the payload. The use of the BFD Echo function in
modes other than defined in [RFC5880], e.g.,
[I-D.ietf-bfd-unaffiliated-echo], and other types of BFD Echo payload
are outside the scope of this document.
Because the remote BFD system does not process Echo BFD, the value of
the Your Discriminator field MUST be set to the discriminator of the
local BFD system assigned to the given BFD session. My Discriminator
field MUST be zeroed. To ensure that the BFD Echo packet is returned
to the sender without being processed, the sender MAY use a Binding
SID[RFC8402] that has been bound with the SR Policy that ensures the
return of a packet to that particular node.
7. Use of S-BFD in SR-MPLS
Seamless BFD (S-BFD), defined in [RFC7880], maintains essential
characteristics and elements of the base BFD mechanism described in
[RFC5880] with a lighter approach to instantiating a BFD session
between BFD peers. Similar to the BFD Asynchronous mode, S-BFD is
capable of monitoring a segment list of a p2p SR Policy.
Considering that a particular SR Policy can include multiple
candidate paths, which, in turn, have one or more segment lists, it
could be beneficial to monitor each segment list independently. To
achieve that, the S-BFD Reflector advertises My Discriminator value.
Then, the S-BFD Initiator uses the advertised My Discriminator value
as Your Discriminator value in the BFD Control messages transmitted
over the segment list of the SR Policy. Furthermore, the S-BFD
Initiator assigns a unique My Discriminator for each S-BFD session
monitoring a segment list. S-BFD Reflector transmits BFD Control
messages as IP/UDP packets, taking advantage of the available
resilience mechanisms of the IP network. From that point, to
minimize the detection of failures in the IP network that do not
affect the monitored segment list, it is reasonable not to use defect
detection intervals that are close to the IP network repair time.
Instead, having an S-BFD a detection interval three times longer than
the IP network repair time is practical.
Mirsky, et al. Expires 5 August 2025 [Page 8]
Internet-Draft BFD in SPRING MPLS February 2025
8. IANA Considerations
8.1. Non-FEC Path TLV
IANA is requested to assign a new TLV type from the 31740-31743 range
of the registry "Sub-TLVs for TLV Types 1, 16, and 21" of the
"Multiprotocol Label Switching Architecture (MPLS) Label Switched
Paths (LSPs) Ping Parameters" group as defined in Table 1.
+=======+==================+===============+==================+
| Value | TLV Name | Reference | Sub-TLV Registry |
+=======+==================+===============+==================+
| TBD1 | Non-FEC Path TLV | This document | Path sub-TLV |
+-------+------------------+---------------+------------------+
Table 1: New Non-FEC Path TLV
IANA is requested to create new Non-FEC Path sub-TLV registry for the
Non-FEC Path TLV, as described in Table 2.
Mirsky, et al. Expires 5 August 2025 [Page 9]
Internet-Draft BFD in SPRING MPLS February 2025
+=============+================+=============================+
| Range | Registration | Note |
| | Procedures | |
+=============+================+=============================+
| 0-16383 | Standards | This range is for sub-TLVs |
| | Action | that require an error |
| | | message if not recognized |
| | | (Section 4.1 of [RFC9041]). |
+-------------+----------------+-----------------------------+
| 16384-31739 | RFC Required | This range is for sub-TLVs |
| | | that require an error |
| | | message if not recognized |
| | | (Section 4.1 of [RFC9041]). |
+-------------+----------------+-----------------------------+
| 31740-31743 | Experimental | This range is for sub-TLVs |
| | Use. Reserved, | that require an error |
| | not to be | message if not recognized |
| | assigned. | (Section 4.1 of [RFC9041]). |
+-------------+----------------+-----------------------------+
| 31744-32767 | First Come | This range is for sub-TLVs |
| | First Served | that require an error |
| | | message if not recognized |
| | | (Section 4.1 of [RFC9041]). |
+-------------+----------------+-----------------------------+
| 32768-49161 | Standards | This range is for optional |
| | Action | TLVs that can be silently |
| | | dropped if not recognized. |
+-------------+----------------+-----------------------------+
| 49162-64507 | RFC Required | This range is for optional |
| | | TLVs that can be silently |
| | | dropped if not recognized. |
+-------------+----------------+-----------------------------+
| 64508-64511 | Experimental | This range is for optional |
| | Use. Reserved, | TLVs that can be silently |
| | not to be | dropped if not recognized. |
| | assigned. | |
+-------------+----------------+-----------------------------+
| 64512-65535 | First Come | This range is for optional |
| | First Served | TLVs that can be silently |
| | | dropped if not recognized. |
+-------------+----------------+-----------------------------+
Table 2: Non-FEC Path sub-TLV registry
IANA is requested to allocate the following values from the Non-FEC
Path sub-TLV registry as defined in Table 3.
Mirsky, et al. Expires 5 August 2025 [Page 10]
Internet-Draft BFD in SPRING MPLS February 2025
+=======+==================================+===============+
| Value | Description | Reference |
+=======+==================================+===============+
| 0 | Reserved | This document |
+-------+----------------------------------+---------------+
| 1 | SR Policy's Segment List sub-TLV | This document |
+-------+----------------------------------+---------------+
| 65535 | Reserved | This document |
+-------+----------------------------------+---------------+
Table 3: New SR Segment List sub-TLV
8.2. Return Code
IANA is requested to create Non-FEC Path sub-TLV sub-registry for the
new Non-FEC Path TLV and assign a new Return Code value from the
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" registry, "Return Codes" sub-registry, as follows
using a value from the RFC Required range.
+=======+=========================+===============+
| Value | Description | Reference |
+=======+=========================+===============+
| TBD3 | Too Many TLVs Detected. | This document |
+-------+-------------------------+---------------+
Table 4: New Return Code
9. Implementation Status
Note to RFC Editor: This section MUST be removed before publication
of the document.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
Mirsky, et al. Expires 5 August 2025 [Page 11]
Internet-Draft BFD in SPRING MPLS February 2025
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
- The organization responsible for the implementation: ZTE
Corporation.
- The implementation's name ROSng SW empowers traditional routers,
e.g., ZXCTN 6000.
- A brief general description: A list of SIDs can be specified as the
Return Path for an SR-MPLS segment list.
- The implementation's level of maturity: production.
- Coverage: complete
- Version compatibility: draft-mirsky-spring-bfd-06.
- Licensing: proprietary.
- Implementation experience: Appreciate Early Allocation of values
for Non-FEC TLV and SR Policy's Segment List sub-TLV (using First
Come First Served code points).
- Contact information: Qian Xin qian.xin2@xxxxxxxxxx
- The date when information about this particular implementation was
last updated: 12/16/2019
10. Security Considerations
This document describes the specifics of using MPLS LSP Ping, BFD,
and BFD for multipoint networks for the Segment Routing network with
the MPLS data plane. Since all the discussed tools have been used in
MPLS networks, there are no additional security risks. The security
considerations discussed in [RFC5880], [RFC5884], [RFC8562],
[RFC8563], [RFC7726], [RFC8029], [RFC6428], [RFC7880], [RFC8287],
[RFC8402], [RFC9524], [RFC9612], and [RFC9256] apply to this
document.
Mirsky, et al. Expires 5 August 2025 [Page 12]
Internet-Draft BFD in SPRING MPLS February 2025
11. The Scope of the Experiment
The experimental part included in this document is limited to the use
of Non-FEC Path TLV in BFD Reverse Path TLV [RFC9612]. The goal of
the experiment with the Non-FEC Path TLV is validation that its use
does not adversely affect the defect detection in the forward
direction while reducing the number of BFD sessions between a pair of
label switching routers without reporting additional false-negative
events.
12. Contributors
Xiao Min
ZTE Corp.
Email: xiao.min2@xxxxxxxxxx
13. Acknowledgments
Authors express their sincere gratitude to Alexander "Sasha"
Vainshtein for his helpful comments and thought-inspiring discussion
of SR Policies and BFD-based mechanisms. Authors greatly appreciate
the help of Qian Xin, who provided the information about the
implementation of this specification.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010,
<https://www.rfc-editor.org/info/rfc5881>.
Mirsky, et al. Expires 5 August 2025 [Page 13]
Internet-Draft BFD in SPRING MPLS February 2025
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
June 2010, <https://www.rfc-editor.org/info/rfc5883>.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <https://www.rfc-editor.org/info/rfc5884>.
[RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed.,
"Proactive Connectivity Verification, Continuity Check,
and Remote Defect Indication for the MPLS Transport
Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011,
<https://www.rfc-editor.org/info/rfc6428>.
[RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S.
Aldrin, "Clarifying Procedures for Establishing BFD
Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726,
DOI 10.17487/RFC7726, January 2016,
<https://www.rfc-editor.org/info/rfc7726>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<https://www.rfc-editor.org/info/rfc7880>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
N., Kini, S., and M. Chen, "Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
<https://www.rfc-editor.org/info/rfc8287>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
Mirsky, et al. Expires 5 August 2025 [Page 14]
Internet-Draft BFD in SPRING MPLS February 2025
[RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
Ed., "Bidirectional Forwarding Detection (BFD) for
Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562,
April 2019, <https://www.rfc-editor.org/info/rfc8562>.
[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
Ed., "Bidirectional Forwarding Detection (BFD) Multipoint
Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,
<https://www.rfc-editor.org/info/rfc8563>.
[RFC9041] Andersson, L., Chen, M., Pignataro, C., and T. Saad,
"Updating the MPLS Label Switched Paths (LSPs) Ping
Parameters IANA Registry", RFC 9041, DOI 10.17487/RFC9041,
July 2021, <https://www.rfc-editor.org/info/rfc9041>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9524] Voyer, D., Ed., Filsfils, C., Parekh, R., Bidgoli, H., and
Z. Zhang, "Segment Routing Replication for Multipoint
Service Delivery", RFC 9524, DOI 10.17487/RFC9524,
February 2024, <https://www.rfc-editor.org/info/rfc9524>.
[RFC9612] Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen,
"Bidirectional Forwarding Detection (BFD) Reverse Path for
MPLS Label Switched Paths (LSPs)", RFC 9612,
DOI 10.17487/RFC9612, July 2024,
<https://www.rfc-editor.org/info/rfc9612>.
14.2. Informative References
[I-D.ietf-bfd-unaffiliated-echo]
Cheng, W., Wang, R., Min, X., Rahman, R., and R. C.
Boddireddy, "Unaffiliated Bidirectional Forwarding
Detection (BFD) Echo", Work in Progress, Internet-Draft,
draft-ietf-bfd-unaffiliated-echo-14, 10 December 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bfd-
unaffiliated-echo-14>.
Mirsky, et al. Expires 5 August 2025 [Page 15]
Internet-Draft BFD in SPRING MPLS February 2025
[I-D.ietf-mpls-p2mp-bfd]
Mirsky, G., Mishra, G. S., and D. E. Eastlake,
"Bidirectional Forwarding Detection (BFD) for Multipoint
Networks over Point-to-Multi-Point MPLS Label Switched
Path (LSP)", Work in Progress, Internet-Draft, draft-ietf-
mpls-p2mp-bfd-09, 6 January 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
p2mp-bfd-09>.
[I-D.ietf-pim-p2mp-policy-ping]
Bidgoli, H., Voyer, D., Parekh, R., and Z. J. Zhang, "P2MP
Policy Ping", Work in Progress, Internet-Draft, draft-
ietf-pim-p2mp-policy-ping-08, 24 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pim-
p2mp-policy-ping-08>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed.,
"Multicast VPN Fast Upstream Failover", RFC 9026,
DOI 10.17487/RFC9026, April 2021,
<https://www.rfc-editor.org/info/rfc9026>.
[RFC9186] Mirsky, G. and X. Ji, "Fast Failover in Protocol
Independent Multicast - Sparse Mode (PIM-SM) Using
Bidirectional Forwarding Detection (BFD) for Multipoint
Networks", RFC 9186, DOI 10.17487/RFC9186, January 2022,
<https://www.rfc-editor.org/info/rfc9186>.
Authors' Addresses
Greg Mirsky
Ericsson
Email: gregimirsky@xxxxxxxxx
Jeff Tantsura
NVIDIA
Email: jefftant.ietf@xxxxxxxxx
Ilya Varlashkin
Google
Email: imv@xxxxxxxxxx
Mirsky, et al. Expires 5 August 2025 [Page 16]
Internet-Draft BFD in SPRING MPLS February 2025
Mach(Guoyi) Chen
Huawei
Email: mach.chen@xxxxxxxxxx
Jiang Wenying
CMCC
Email: jiangwenying@xxxxxxxxxxxxxxx
Mirsky, et al. Expires 5 August 2025 [Page 17]
<<< text/html; charset="US-ASCII"; name="draft-ietf-spring-bfd-13.diff.html": Unrecognized >>>
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
