[spring] Re: WGLC Chair review of draft-ietf-spring-bfd-12
Greg Mirsky <[email protected]> Sat, 1 Feb 2025 15:42:58 -0800
| Newsgroups | gmane.ietf.spring,gmane.ietf.rtg-bfd,gmane.ietf.mpls |
|---|---|
| Message-ID | <CA+RyBmUZcSrBzTfs3ymAraQt+A-xviuWmG4XgAUo431nKEJBeA@mail.gmail.com> |
Hi Alvaro, thank you for the thorough review, direct questions, and constructive suggestions. Please find my notes below tagged GIM>>. Attached are the diff that highlights all the updates applied in the working version of the draft. Regards, Greg On Fri, Dec 13, 2024 at 8:38 AM Alvaro Retana <[email protected]> wrote: > > Dear authors: > > In parallel with the WGLC, here's my review of this document. Please > consider the comments with other WGLC input you may receive. > > Thanks! > > Alvaro. > > > [Line numbers from idnits.] > > ... > 18 Abstract > > 20 Segment Routing (SR) architecture leverages the paradigm of source > 21 routing. It can be realized in the Multiprotocol Label Switching > 22 (MPLS) network without changing the data plane. Bidirectional > 23 Forwarding Detection (BFD) is expected to monitor a segment list, > 24 representing a specific source-routed SR Policy path between the > 25 headend and an endpoint. This document describes using BFD for > 26 monitoring individual segment lists of candidate paths of an SR > 27 Policy. It documents the use of various BFD modes and features such > 28 as BFD Demand mode, Seamless BFD, and BFD Echo function with the BFD > 29 Control packet payload in the SR-MPLS domain. Also, this document > 30 defines how to use Label Switched Path Ping to bootstrap a BFD > 31 session, with optional control of selecting a segment list in the > 32 reverse direction of the BFD session. > > [nit] s/Segment Routing (SR) architecture/The Segment Routing (SR) > architecture > GIM>> Applied > > > [nit] "(BFD) is expected to monitor" > > I don't think that expectation is expressed anywhere (outside this > draft). Given that the next sentence talks about what this draft describes > and that the expectation is only called out here, we can live without this > sentence in the Abstract. > GIM>> Agreed and moved the expanded form of BFD to the next sentence. > > > > ... > 64 Table of Contents > ... > 76 4. Applicability of BFD Demand Mode in SR-MPLS Domain . . . . . 7 > 77 5. Using BFD to Monitor Point-to-Multipoint SR Policy . . . . . 8 > 78 6. Use of Echo BFD in SR-MPLS . . . . . . . . . . . . . . . . . 8 > 79 7. Use of S-BFD in SR-MPLS . . . . . . . . . . . . . . . . . . . 9 > > [minor] This document describes several BFD options. What should an > operator consider when selecting one over another? For example, are there > differences related to the number of sessions? It would be nice if there > were a short section talking about the pros/cons. > GIM>> I agree that that is an important and helpful to operators topic. My concern is that it might be challenging to separate technical and non-technical arguments. It could be helpful if we collect feedback and experiences from operators in a blind poll. WDYT? > > > > ... > 93 1. Introduction > > 95 [RFC5880], [RFC5881], and [RFC5883] defined the operation of > 96 Bidirectional Forwarding Detection (BFD) protocol between the two > 97 systems over IP networks. [RFC5884] and [RFC7726] set rules for > 98 using BFD Asynchronous mode over point-to-point (p2p) Multiprotocol > 99 Label Switching (MPLS) Label Switched Path (LSP). These latter > 100 standards implicitly assume that the remote BFD system, which is at > 101 the egress Label Edge Router (LER), will use the shortest path route > 102 regardless of the path the BFD system at the ingress LER uses to > send > 103 BFD Control packets towards it. Throughout this document, > references > 104 to ingress LER and egress LER are used, respectively, as a shortened > 105 version of the "BFD system at the ingress/egress LER". > > [nit] s/defined the operation/define the operation > GIM>> Done > > > [nit] s/operation of Bidirectional Forwarding Detection (BFD) protocol > between/ > > operation of the Bidirectional Forwarding Detection (BFD) protocol between > > OR > > operation of Bidirectional Forwarding Detection (BFD) between > GIM>> The former > > > [nit] s/between the two systems/between two systems > GIM>> Thank you > > > [minor] "will use the shortest path route" -- for what? > > This phrase seems incomplete: "to respond", or "sent xxx back"... > GIM>> Thank you for pointing out this ambiguity. In BFD Asynchronous mode, each BFD system periodically transmits a BFD Control message. In the BFD Echo function and Seamless BFD, the remote BFD system responds to the received BFD Control message. Although that is not discussed later in the document, the remote BFD system maintains the state of the BFD session only in the BFD Asynchronous mode. Would the following update make it more evident: OLD TEXT: 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 regardless of the path the BFD system at the ingress LER uses to send BFD Control packets towards it. NEW TEXT: 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. > > > > [minor] "Throughout this document..." Maybe better suited for the > Terminology section. > GIM>> I moved that sentence and re-named the section as Terminology and Abbreviations > > > > 107 [RFC9256] defines the SR Policy architecture. When analyzing the > 108 applicability of a BFD-based mechanism for detecting network > failures > 109 in a Segment Routing domain, it is essential to identify the SR > 110 Policy elements monitored by the BFD. Concluding from the > definition > 111 of BFD in [RFC5880], in an SR domain, BFD, in its modes and > 112 functions, monitors not the SR Policy, as defined in [RFC9256], but > a > 113 segment list that is a constituent of the candidate path of the > 114 particular SR Policy. That is the context used throughout the > 115 document. > > [nit] s/identify the SR Policy elements monitored by the BFD/identify the > monitored SR Policy elements > GIM>> Thank you. > > > [major] "Concluding from the definition of BFD in [RFC5880], in an SR > domain, BFD, in its modes and functions, monitors not the SR Policy, as > defined in [RFC9256], but a segment list that is a constituent of the > candidate path of the particular SR Policy. That is the context used > throughout the document." > > I had to read the first sentence several times; it is more complex than it > should be. > > Instead of asking which definitions of BFD and "SR Policy" you're > referring to or pointing at the fact that rfc5880 doesn't talk about SR, > I'm assuming these two sentences intend to set the context. > > Suggestion> > > In this document, BFD is used to monitor a segment list that is a > constituent of a candidate path of a particular SR Policy. > > This suggestion is similar to the text in the next paragraph, so I would > be equally happy if you just removed the last two sentences above. > GIM>> Thank you for thoroughly considering the text and thoughtful suggestion. I removed sentences. > > > 117 This document describes the use of BFD for monitoring individual > 118 segment lists of candidate paths of an SR Policy. It documents the > 119 use of various BFD modes and features such as BFD Demand mode, > 120 Seamless BFD, and BFD Echo function with the BFD Control packet > 121 payload. in the SR-MPLS domain. Also, this document defines the use > 122 of LSP Ping for Segment Routing networks over the MPLS data plane > 123 [RFC8287] to bootstrap and control path of a BFD session from the > 124 egress LER to the ingress LER using Segment Routing segment list > with > 125 MPLS data plane (SR-MPLS). > > 127 1.1. Conventions > > 129 1.1.1. Terminology > ... > 139 SR-MPLS Segment Routing with MPLS data plane > 140 LSP: Label Switched Path > > [nit] Some entries have a colon, and some don't. > GIM>> Normalized to a colon throughout the section. > > > > ... > 162 2. Initialization of a BFD Session Over a Segment List with MPLS Data > 163 Plane > > 165 Use of an LSP Ping to bootstrap BFD over an MPLS LSP is required, as > 166 documented in [RFC5884], to establish an association between a fault > 167 detection message, i.e., BFD Control message, and the Forwarding > 168 Equivalency Class (FEC) of a single label stack LSP in case of > 169 Penultimate Hop Popping or when the egress LER distributes the > 170 Explicit NULL label to the penultimate hop router. The Explicit > NULL > 171 label is not advertised as a Segment Identifier (SID) by an SR node > 172 but, as demonstrated in section 3.1 [RFC8660] if the operation at > the > 173 penultimate hop is NEXT; then the egress SR node will receive an IP > 174 encapsulated packet. Furthermore, even if the endpoint receives an > 175 MPLS encapsualted packet, the top label might be an Adjacency SID or > 176 Prefix SID which doesn't provide the context for the SR segment > list. > 177 Thus the conclusion is that LSP Ping MUST be used to bootstrap a BFD > 178 session in an SR-MPLS domain if there are no other means to > bootstrap > 179 the BFD session, e.g., using an extension to a dynamic routing > 180 protocol as described in [RFC9026] and [RFC9186]. > > [minor/major] Wow! Many of the sentences (in this paragraph and elsewhere > in the draft) are long and convoluted -- making the text hard to understand > and prone to misinterpretation. The sentences above are prime examples. :-( > > To illustrate... "Use of an LSP Ping to bootstrap BFD over an MPLS LSP is > required, as documented in [RFC5884], to establish..." Is the use of LSP > Ping required by rfc5884, or is the behavior in rfc5884 required (by this > document), or are you simply saying that rfc5884 requires the use of LSP > Ping to establish... ? > > If rfc5884 is a document that "must be read to understand or implement the > technology" [1] in this draft, you don't need to include all the > background. But listing it as a Normative reference is enough. > > [1] > https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normative-and-informative-references-20060419/ > > > The conclusion in the last sentence is the only piece that is needed. > However, I believe the "MUST" should be changed to a "SHOULD" given that > there are alternatives. > > Suggestion (for the whole paragraph)> > > 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]. > GIM>> Thank you for reminding me that "Brevity is the sister of talent" (A. Chekhov). > > > > 182 As demonstrated in [RFC8287], the introduction of Segment Routing > 183 network domains with an MPLS data plane requires three new sub-TLVs > 184 that MAY be used with Target FEC TLV [RFC8029]. Section 6.1 > 185 addresses the use of the new sub-TLVs in Target FEC TLV in LSP ping > 186 and LSP traceroute. For the case of LSP ping, the [RFC8287] states > 187 that: > > 189 The initiator, i.e., ingress LER, MUST include FEC(s) > 190 corresponding to the destination segment. > > 192 The initiator MAY include FECs corresponding to some or all of > 193 segments imposed in the label stack by the ingress LER to > 194 communicate the segments traversed. > > [major] Several points...starting with: I don't understand the value of > mentioning the details of what other RFCs specify. The same can be > obtained by Normatively referencing them or otherwise pointing at specific > sections (if needed). > > rfc8287 specified (didn't "demonstrate") the new sub-TLS. > > The "MAY" is out of place because that normative behavior is specified in > rfc8287 and not here. You can either quote the text or paraphrase it (for > example, "the use of the new sub-TLVs is optional [RFC8287]"). > > There is no "Section 6.1" in rfc8287; you probably refer to §7.1. > > To all this...why do you need to include this text in this draft? There's > no statement related to how this text is used in the context of this > draft. Maybe all you need is text such as: "The procedures specified in > [RFC8287] for using LSP Ping with an MPLS data plane MUST be used." > GIM>> Thank you for reminding me that a reader is expected to obtain knowledge and understanding of the existing specifications, at least those listed as Normative references. I replaced the text with the sentence you proposed. > > > > 196 It has been noted in [RFC5884] that a BFD session monitors for > 197 defects particular <MPLS LSP, FEC> tuple. [RFC7726] clarified how > to > 198 establish and operate multiple BFD sessions for the same <MPLS LSP, > 199 FEC> tuple. Because only the ingress LER is aware of the SR-based > 200 explicit route, the egress LER can associate the LSP ping with BFD > 201 Discriminator TLV with only one of the FECs it advertised for the > 202 particular segment. Thus this document clarifies that: > > 204 When LSP Ping is used to bootstrapping a BFD session for SR-MPLS > 205 segment list the FEC corresponding to the last segment to be > 206 associated with the BFD session MUST be as the very last sub-TLV > 207 in the Target FEC TLV. > > [major] Again, multiple comments... > > Because rfc7726 Updates rfc5884, you don't need to mention the whole story. > > What do you mean when you say, "this document clarifies…"? Are you saying > it in the same way that rfc7726 clarified rfc5884? Or are you specifying a > behavior in the context of this document? > > As to the clarifying text, I now see that the "clarification" is really an > addition to the text in §7.1/rfc7726 related to Ping -- right? If so, and > assuming that the Normative text should read "MUST be the very last" (and > not "MUST be as the very last"), what is new? The text in §7.1/rfc7726 > already requires a FEC for the destination segment, which I assume to be > the last one... What am I missing? > GIM>> Thank you for pointing out another over-verbose passage. Would the following update be acceptable: OLD TEXT: It has been noted in [RFC5884] that a BFD session monitors for defects particular <MPLS LSP, FEC> tuple. [RFC7726] clarified how to establish and operate multiple BFD sessions for the same <MPLS LSP, FEC> tuple. Because only the ingress LER is aware of the SR-based explicit route, the egress LER can associate the LSP ping with BFD Discriminator TLV with only one of the FECs it advertised for the particular segment. Thus this document clarifies that: 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. NEW TEXT: 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]. > > > [major] What if the last/destination segment is a BSID? I don't think > there's a FEC defined for that...even if it should be possible to monitor > the SL, at least up to that point. Is this case not supported? > GIM>> A good question. Can we have a scenario in which BSID terminates an SR Policy? I imagine that BSID might be used to control the depth of the label stack, but I cannot come up with a case where BSID is the last in SR Policy as, in my understanding, it will be replaced by a list of SIDs. Am I missing something here? > > > > 209 Encapsulation of a BFD Control packet in Segment Routing network > with > 210 MPLS data plane MUST follow Section 7 [RFC5884] when the IP/UDP > 211 header used and MUST follow Section 3.4 [RFC6428] without IP/UDP > 212 header being used. > > [nit] s/the IP/UDP header used/an IP/UDP header is used > GIM>> Thank you. > > > [nit] s/without IP/UDP header being used/if the IP/UDP header is not used > GIM>> Done, thx. > > > > 214 3. Using BFD Reverse Path TLV over SR Policy's Segment List > > 216 For BFD over MPLS LSP case, per [RFC5884], egress LER MAY send BFD > 217 Control packet to the ingress LER either over IP network or an MPLS > 218 LSP. Similarly, for the case of BFD over p2p SR-MPLS segment list, > 219 the egress LER MAY route BFD Control packet over the IP network, as > 220 described in [RFC5883], or transmit over a segment list, as > described > 221 in Section 7 [RFC5884]. In some cases, there may be a need to > direct > 222 egress LER to use a specific path for the reverse direction of the > 223 BFD session by using the BFD Reverse Path TLV and following all > 224 procedures as defined in [RFC9612]. > > [major] "For BFD over MPLS LSP case, per [RFC5884], egress LER MAY send > BFD Control packet to the ingress LER either over IP network or an MPLS > LSP." > > This behavior is already specified in RFC5884, so there should be no > Normative language here -- unless it is to point at the other RFC in > general. Also, note that the text above makes sending optional ("MAY > send”), not the election. > > Suggestion> > > For the BFD over MPLS LSP case, the egress LER SHOULD send BFD > Control packets to the ingress LER either based on the destination > IP address or encapsulated in an MPLS label stack as specified in > [RFC5884]. > GIM>> Thank you for bringing up this question. As I understand RFC 5884, egress LER MUST use one of two encapsulations - IP/UDP or MPLS. It seems that if we say SHOULD, then there might be yet another encapsulation option. Perhaps the following update accurately reflects encapsulation options: OLD TEXT: For BFD over MPLS LSP case, per [RFC5884], egress LER MAY send BFD Control packet to the ingress LER either over IP network or an MPLS LSP. NEW TEXT: 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. > > > [major] "Similarly, for the case of BFD over p2p SR-MPLS segment list, the > egress LER MAY route BFD Control packet over the IP network, as described > in [RFC5883], or transmit over a segment list, as described in Section 7 > [RFC5884]." > > Same comment as above about the "MAY": it makes sending optional. > > I couldn't find a mention of "egress" in rfc5883, but I guess you mean the > procedure in §5 (Encapsulation). ?? > > The text in §7/rfc5884 is what I thought you were referring to in the > previous sentence -- it's ok to use the same process. You may want to also > refer to §7 in the first sentence. rfc5884 doesn't use the "segment list" > language, so it is not "as described" there. Please use language that is > consistent with the source. > > Suggestion> > > For the case of BFD over a p2p SR-MPLS segment list, the egress LER > SHOULD 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]. > GIM>> As discussed in the note above, I think "MUST use one of two encapsulations" will reflect the message's intention more accurately. Hence, I propose s/SHOULD/MUST/ in the text you suggest: NEW TEXT: 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]. > > > [major] "In some cases, there may be a need to direct egress LER to use a > specific path for the reverse direction of the BFD session by using the BFD > Reverse Path TLV and following all procedures as defined in [RFC9612]." > > "In some cases..." Which cases? The sentence seems to imply that you're > either talking about scenarios that the last two sentences don't address > (i.e., not using "BFD over MPLS LSP case" or "BFD over a p2p SR-MPLS > segment list") OR cases where other considerations should come into play. > This is a case where you want to be explicit with the justification behind > rfc9612. > > Suggestion (new paragraph)> > > 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. > GIM>> Thank you for the suggested text. I agree with your proposal. > > > > 226 3.1. Use Non-FEC Path TLV > ... > 246 Non-FEC Path TLV Type is two octets in length and has a value of > TBD1 > 247 (to be assigned by IANA as requested in Section 8.1). > > [nit] s/Non-FEC Path TLV Type/The Non-FEC Path TLV Type field > GIM>> Thanks! Done. > > > [nit] s/(...)/ > GIM>> I couldn't find it. > > > > 249 Length field is two octets long and defines the length in octets of > 250 the Non-FEC Path field. > > [nit] s/Length field/The Length field > GIM>> Done. > > > > 252 Non-FEC Path field contains a sub-TLV. Any Non-FEC Path sub-TLV > 253 (defined in this document or to be defined in the future) for > Non-FEC > 254 Path TLV type MAY be used in this field. None or one sub-TLV MAY be > 255 included in the Non-FEC Path TLV. If no sub-TLV has been found in > 256 the Non-FEC Path TLV, the egress LER MUST revert to using the > reverse > 257 path selected based on its local policy. If there is more than one > 258 sub-TLV, then the Return Code in echo reply MUST be set to value > TBD3 > 259 "Too Many TLVs Detected" (to be assigned by IANA as requested in > 260 Table 4). > > [nit] s/Non-FEC Path field/The Non-FEC Path field > > > [minor] s/(...)/ x2 > GIM>> It seems like, in some cases, XML2RFC inserts extra spaces to format a paragraph. > > > [major] "MAY be used in this field" implies that the use of these sub-TLVs > is optional (and that there may be others). > > s/MAY/may > GIM>> I agree. > > > [major] "Non-FEC Path field contains a sub-TLV. ... None or one sub-TLV > MAY be included in the Non-FEC Path TLV." > > The first sentence implies 1... > > Suggestion> > > The Non-FEC Path field MUST contain at most one sub-TLV. > GIM>> Thank you for the suggestion; I applied it to the working version. > > > > 262 Non-FEC Path TLV MAY be used to specify the reverse path of the BFD > 263 session identified in the BFD Discriminator TLV. If the Non-FEC > Path > 264 TLV is present in the echo request message the BFD Discriminator TLV > 265 MUST be present as well. If the BFD Discriminator TLV is absent > when > 266 the Non-FEC Path TLV is included, then it MUST be treated as > 267 malformed Echo Request, as described in [RFC8029]. > > [major] [Assuming the Non-FEC Path TLV is a sub-TLV of the BFD Reverse > Path TLV...] The text above is unnecessary because the behavior is already > specified in rfc9612. > GIM>> Removed the text accordingly. > > > [major] §11 (The Scope of the Experiment) mentions the use of the "Non-FEC > Path TLV in BFD Reverse Path TLV", which I interpret as the Non-FEC Path > TLV is a sub-TLV of the BFD Reverse Path TLV. However, as defined in this > document (see the request in §8.1), the Non-FEC Path TLV can't be used as a > sub-TLV of the BFD Reverse Path TLV because §3.1/RFC9612 specifies: > > Only non-multicast Target FEC Stack sub-TLVs (already defined or > to be defined in the future) for TLV Types 1, 16, and 21 in the > "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) > Ping Parameters" registry are permitted to be used in this field. > Other sub-TLVs MUST NOT be used." > > If the intent is to use the "Non-FEC Path TLV in BFD Reverse Path TLV", > the definition won't allow it. > GIM>> Thank you for catching this major issue. I propose updating Section 8.1. Non-FEC Path TLV as follows: OLD TEXT: IANA is requested to assign new TLV type from the from 16384-31739 range of the registry "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" as defined in Table 1. NEW TEXT: IANA is requested to assign a new TLV type from the 31740-31743 range of the registry "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - Sub-TLVs for TLV Types 1, 16, and 21" as defined in Table 1. > > [major] How should the Non-FEC Path TLV interact with any other possible > sub-TLVs in the BFD Reverse Path TLV? [rfc9612 is, unfortunately, silent > about any interaction.] > GIM>> A good question, thank you. Should this document make the use of Non-FEC Path TLV mutually excluded any other sub-TLV that might be defined in the future? I think that that must be explicitly specified in documents introducing new sub-TLVs. Would you agree? > > > > 269 This document defines the SR Policy's Segment List sub-TLV that MAY > 270 be used with the Non-FEC Path TLV. The format of the sub-TLV is > 271 presented in Figure 2. > > [] Please put the specification of this sub-TLV in a new sub-section. > GIM>> Put it into the new sub-section titled SR Policy's Segment List sub-TLV > > > > ... > 289 The SR Policy's Segment List sub-TLV Type is two octets in length, > 290 and has a value of TBD2 (to be assigned by IANA as requested in > 291 Section 8.1). > > [nit] s/(...)/ > > > [major] Even if obvious, you must define the Length field. > GIM>> Added the following: NEW TEXT: The Length field is two octets long and defines the length in octets of Label Stack Entries listed in that sub-TLV. > > > > 293 Label Stack Entries [RFC3032] MUST be in network order. The egress > 294 LER MUST use the Label fields of the Label Stack Entry field as > label > 295 stack for BFD Control packets for the BFD session identified by the > 296 source IP address of the MPLS LSP Ping packet and the value in the > 297 BFD Discriminator TLV. > > [major] The Label Stack Entry field hasn't been defined. Please do so > before describing how the entries should be used. > GIM>> Prepended that paragraph with the following sentence: NEW TEXT: The Label Stack Entry field is four octets long and is the label stack entry as defined in Section 2.1 of [RFC3032]. > > > [minor] The SR Policy's Segment List sub-TLV is an ordered list of > labels. Several Type-A Segment Sub-TLVs > [draft-ietf-mpls-spring-inter-domain-oam] could also be used in the BFD > Reverse Path TLV to describe an ordered list of labels. Is there a > functional difference between the two? [This question is related to the > interaction question above.] > GIM>> An excellent and thought-provoking question! AFAICS, Type-A Segment sub-TLV allows only single label stack entry. Is that a useful way to specify the return path in an SR domain? It seems like it could be used if the sub-TLV carries B-SID. As for the interaction, since both sub-TLVs to be listed in IANA's "Sub-TLVs for TLV Types 1, 16, and 21" sub-registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", they, as I understand it, are inherently mutually exclusive. > > > > 299 3.2. BFD Reverse Path TLV over SR Policy's Segment List with Dynamic > 300 Control Plane > > 302 When Segment Routed domain with MPLS data plane uses distributed > 303 computation of SR Policy's segment lists, BFD Reverse Path TLV MAY > 304 use Target FEC sub-TLVs defined in [RFC8287]. > > [nit] s/Segment Routed domain/a Segment Routed domain > GIM>> Done. > > > [major] "When...uses distributed computation of SR Policy's segment lists, > BFD Reverse Path TLV MAY use..." > > How do the senders/receivers know that a controller is not used? Is this > a known configuration setting? > GIM>> As I understand RFC 8287, the new Target FEC sub-TLVs defined in it apply to domains where SIDs are distributed using either a label distribution protocol (e.g., LDP, RSVP-TE) or an SR extension of an IGP. Although that seems sub-optimal, these mechanisms may be used concurrently with a centralized controller. Would the update listed below make it less ambiguous? > > > [major] "BFD Reverse Path TLV MAY use..." > > The BFD Reverse Path TLV already allows the use of *any* sub-TLV, so > there's no need to specify this here. Even if needed, this document isn't > Updating rfc9612 to change the behavior or limit what is already allowed. > GIM>> Updated with using the normative words: OLD TEXT: When Segment Routed domain with MPLS data plane uses distributed computation of SR Policy's segment lists, BFD Reverse Path TLV MAY use Target FEC sub-TLVs defined in [RFC8287]. NEW TEXT: Target FEC sub-TLVs defined in [RFC8287] are applicable in SR domains that are in the scope of [RFC8287]. > > > > 306 4. Applicability of BFD Demand Mode in SR-MPLS Domain > > 308 Sections 6.6 and 6.18.4 of [RFC5880] define how Demand mode of BFD > 309 can be used to monitor uni-directional MPLS LSP. Similar procedures > 310 can be following in SR-MPLS to monitor uni-directional SR tunnels: > > [minor] "6.18.4 of [RFC5880]" doesn't exist. > GIM>> Strange because I find it here https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.14 <https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.14> > > > [nit] s/can be following/can be followed > GIM>> Thank you! > > > > 312 * an ingress SR node bootstraps BFD session over SR-MPLS in Async > 313 BFD mode; > > [nit] s/bootstraps BFD session/bootstraps the BFD session > GIM>> Got it; thx! > > > > 315 * once BFD session is Up, the ingress SR node switches the egress > 316 LER into the Demand mode by setting D field in BFD Control packet > 317 it transmits; > > [nit] s/once BFD session/once the BFD session > GIM>> Done. > > > > ... > 329 5. Using BFD to Monitor Point-to-Multipoint SR Policy > > 331 [RFC9524] defined variants of SR Policy to deliver point-to- > 332 multipoint (p2mp) services. For the given segment list of an p2mp > SR > 333 Policy, [RFC8562] can be used if, for example, leaves have an > 334 alternative source of the multicast service flow to select. In such > 335 a scenario, a leaf may switch to using the alternative flow after > 336 p2mp BFD detects the failure in the working multicast path. For > 337 scenarios where it is required for the root to monitor the state of > 338 the multicast tree [RFC8563] can be used. The root may use the > 339 detection of the failure of the multicast tree to the particular > leaf > 340 to restore the path for that leaf or re-instantiate the whole > 341 multicast tree. > > [nit] To make reading easier, please use descriptive names when referring > to RFCs that others may not be familiar with. > GIM>> Added the full title of RFCs 9524, 852, and 8563 as follows: NEW TEXT: 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. > For example: > > s/[RFC8562] can be used/BFD for Multipoint Networks [RFC8562] can be used > > > > 343 An essential part of using p2mp BFD is the bootstrapping the BFD > 344 session at all the leaves. The root, acting as the MultipointHead, > 345 MAY use LSP Ping [I-D.ietf-pim-p2mp-policy-ping] with the BFD > 346 Discriminator TLV. Alternatively, extensions to routing protocols, > 347 e.g., BGP, or management plane, e.g., Path Computation Element > 348 Protocol, MAY be used to associate the particular p2mp segment list > 349 with MultipointHead's Discriminator. Extensions for routing > 350 protocols and management plane are for further study. > > [major] "extensions to routing protocols...or management plane...MAY be > used... Extensions for routing protocols and management plane are for > further study." > > We can't use Normative language to point at things that are not defined. > You should be able to delete the last two sentences without losing > information. > > Alternatively, here's a suggestion: > > 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. > GIM>> Thank you for pointing this out. We missed to reference work on the BGP-BFD Attribute in RFC 9026. Would the following update be acceptable: OLD TEXT: Alternatively, extensions to routing protocols, e.g., BGP, or management plane, e.g., Path Computation Element Protocol, MAY be used to associate the particular p2mp segment list with MultipointHead's Discriminator. Extensions for routing protocols and management plane are for further study. NEW TEXT: 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. > > > 352 6. Use of Echo BFD in SR-MPLS > > 354 Echo-BFD [RFC5880] can be used to monitor a segment list of the > 355 particular SR Policy between the local and the remote BFD peers. As > 356 defined in [RFC5880], the remote BFD system does not process the > 357 payload of an Echo BFD. Thus it is the local system that > 358 demultiplexes the Echo BFD packet matching it to the appropriate BFD > 359 session and detects missing Echo BFD packets. A BFD Control packet > 360 MAY be used as the payload of Echo BFD. This specification defines > 361 the use of Echo BFD in SR-MPLS network with BFD Control packet as > the > 362 payload. The use of other types of Echo BFD payload is outside the > 363 scope of this document. Because the remote BFD system does not > 364 process Echo BFD, the value of the Your Discriminator field MUST be > 365 set to the discriminator the local BFD system assigned to the given > 366 BFD session. My Discriminator field MUST be zeroed. Authentication > 367 MUST be set according to the configuration of the BFD session. To > 368 ensure that the Echo BFD packet is returned to the sender without > 369 being processed, the sender MAY use a Binding SID (BSID) [RFC8402] > 370 that has been bound with the SR Policy that ensures the return of a > 371 packet to that particular node. A BSID MAY be associated with the > SR > 372 Policy that is the reverse to the SR Policy programmed onto the BFD > 373 Echo packet by the sender. > > [major] "Authentication MUST be set according to the configuration of the > BFD session." > > Ahhh...ok. IOW, use authentication if configured and don't use it if not > configured. Is that what you mean? > GIM>> Yes, that is the intention. > I don't see any Normative/interoperability value in using Normative > language -- or any value in the sentence itself. > GIM>> Removed the sentence altogether. > > Why isn't authentication mentioned anywhere else? > GIM>> SR-MPLS does not present any new security threats that have not already been discussed in RFC 5884. > > > [major] "...the sender MAY use a Binding SID (BSID) [RFC8402] that has > been bound with the SR Policy that ensures the return of a packet to that > particular node. A BSID MAY be associated with the SR Policy that is the > reverse..." > > These two sentences specify the same behavior. The second one can be > deleted. > GIM>> Agree. > > > [minor] In the case where the BSID is used, what would the encapsulation > look like? In both directions... > GIM>> I imagine the BSID will be in the BoS LSE. The reflecting LSR will replace the BSID with the associated list of SIDs before transmitting it. > > > > 375 7. Use of S-BFD in SR-MPLS > ... > 383 Considering that a particular SR Policy can include multiple > 384 candidate paths, which, in turn, have one or more segment lists, it > 385 could be beneficial to monitor each segment list independently. To > 386 achieve that, S-BFD Reflector advertises My Discriminator value. > 387 Then, the S-BFD Initiator uses the advertised My Discriminator value > 388 as Your Discriminator value in the BFD Control messages transmitted > 389 over the segment list of the SR Policy. Furthermore, the S-BFD > 390 Initiator assigns a unique My Discriminator for each S-BFD session > 391 monitoring a segment list. S-BFD Reflector transmits BFD Control > 392 messages as IP/UDP packets, taking advantage of the available > 393 resilience mechanisms of the IP network. From that point, to > 394 minimize the detection of failures in the IP network that do not > 395 affect the monitored segment list, it is reasonable not to use > defect > 396 detection intervals that are close to the IP network repair time. > 397 Instead, having an S-BFD detection interval three times longer than > 398 the IP network repair time is practical. > > [nit] s/S-BFD Reflector advertises/the S-BFD Reflector advertises > GIM>> Thanks! > > > [major] "...to minimize the detection of failures in the IP network that > do not affect the monitored segment list...[use a] detection interval three > times longer than the IP network repair time is practical." > > This text sounds like good operational advice for any BFD mode; why is it > only mentioned here? I know that S-BFD doesn't negotiate -- applying this > recommendation when configuring the local Tx interval seems important. > GIM>> I agree that this is a general rule for multilayer OAM, i.e., networks with OAM in underlay and overlay. I think that it is helpful to remind it from time to time. > > > > ... > 402 8.1. Non-FEC Path TLV > > 404 IANA is requested to assign new TLV type from the from 16384-31739 > 405 range of the registry "Multiprotocol Label Switching Architecture > 406 (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" as > defined > 407 in Table 1. > > [major] The correct registry is: "Sub-TLVs for TLV Types 1, 16, and 21". > GIM>> I think that IANA changed its hierarchy away from registry - sub-registry to group - registry. Updated as follows: NEW TEXT: 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. > > > > ... > 526 10. Security Considerations > > 528 This document describes the specifics of using MPLS LSP Ping, BFD, > 529 and BFD for multipoint networks for the Segment Routing network with > 530 the MPLS data plane. Since all the discussed tools have been used > in > 531 MPLS networks, there are no additional security risks. Security > 532 considerations discussed in [RFC5880], [RFC5884], [RFC8562], > 533 [RFC8563], [RFC7726], [RFC8029], and [RFC9256] apply to this > 534 document. > > [nit] s/Security considerations discussed/The security considerations > discussed > GIM>> Done. > > > [major] Most Normative references should be listed, please add > draft-ietf-pim-p2mp-policy-ping, RFC6428, RFC7880, RFC8287, RFC8402, > RFC9524, and RFC9612. > GIM>> AFAICS, draft-ietf-pim-p2mp-policy-ping is not the Normative, but Informational reference. Added all the RFCs you suggested: NEW TEXT: The security considerations discussed in [RFC5880], [RFC5884], [RFC8562], [RFC8563], [RFC7726], [RFC8029], [RFC6428], [RFC7880], [RFC8287], [RFC8402], [RFC9524], [RFC9612], and [RFC9256] apply to this document. > > > > 536 11. The Scope of the Experiment > > 538 The experimental part included in this document is limited to the > use > 539 of Non-FEC Path TLV in BFD Reverse Path TLV [RFC9612]. The goal of > 540 the experiment with the Non-FEC Path TLV is validation that its use > 541 does not adversely affect the defect detection in the forward > 542 direction while reducing the number of used BFD sessions between a > 543 pair of LSRs without reporting additional false-negative events. > > [nit] s/number of used BFD sessions/number of BFD sessions > GIM>> Done. > > > > ... > 654 14.2. Informative References > > 656 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., > 657 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack > 658 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, > 659 <https://www.rfc-editor.org/info/rfc3032>. > > [major] This reference should be Normative because there's a "MUST" > associated with it. > GIM>> Done. > > > > 661 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. > 662 Pallagatti, "Seamless Bidirectional Forwarding Detection > 663 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, > 664 <https://www.rfc-editor.org/info/rfc7880>. > > [major] This reference should be Normative because it is needed to > understand §7. > GIM>> Done. > > > > ... > 682 [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, > 683 A., and P. Mattes, "Segment Routing Policy Architecture", > 684 RFC 9256, DOI 10.17487/RFC9256, July 2022, > 685 <https://www.rfc-editor.org/info/rfc9256>. > > [major] This reference should be Normative because understanding the SR > Policy architecture is required for this document. > GIM>> Done. > > [EoR-12] > > _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
draft-ietf-spring-bfd-13.txt
(text/plain, 36.7 KB)
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 [email protected]
- 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: [email protected]
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: [email protected]
Jeff Tantsura
NVIDIA
Email: [email protected]
Ilya Varlashkin
Google
Email: [email protected]
Mirsky, et al. Expires 5 August 2025 [Page 16]
Internet-Draft BFD in SPRING MPLS February 2025
Mach(Guoyi) Chen
Huawei
Email: [email protected]
Jiang Wenying
CMCC
Email: [email protected]
Mirsky, et al. Expires 5 August 2025 [Page 17]
draft-ietf-spring-bfd-13.txt
(text/plain, 36.7 KB)
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 [email protected]
- 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: [email protected]
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: [email protected]
Jeff Tantsura
NVIDIA
Email: [email protected]
Ilya Varlashkin
Google
Email: [email protected]
Mirsky, et al. Expires 5 August 2025 [Page 16]
Internet-Draft BFD in SPRING MPLS February 2025
Mach(Guoyi) Chen
Huawei
Email: [email protected]
Jiang Wenying
CMCC
Email: [email protected]
Mirsky, et al. Expires 5 August 2025 [Page 17]