[spring] Re: WGLC Chair review of draft-ietf-spring-bfd-12

[Alvaro Retana <[e-mail]>]

 FYI — in case the review is truncated, the full review is in the archive:
https://mailarchive.ietf.org/arch/msg/spring/AOOQjydEU3xxZwqEYihoDyVjD2c/

On December 13, 2024 at 11:38:09 AM, Alvaro Retana ([e-mail])
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


[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.



...
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.



...
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


[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


[nit] s/between the two systems/between two systems


[minor] "will use the shortest path route" -- for what?

This phrase seems incomplete: "to respond", or "sent xxx back"...



[minor] "Throughout this document..."  Maybe better suited for the
Terminology section.



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


[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.


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.



...
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].



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."



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?


[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?



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


[nit] s/without IP/UDP header being used/if the IP/UDP header is not used



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].


[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].


[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.



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


[nit] s/(...)/



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



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


[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


[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.



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.


[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.


[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.]



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.



...
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.



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.


[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.]



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


[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?


[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.



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.


[nit] s/can be following/can be followed



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



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



...
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.

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.



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?  I don't see any
Normative/interoperability value in using Normative language -- or any
value in the sentence itself.

Why isn't authentication mentioned anywhere else?


[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.


[minor] In the case where the BSID is used, what would the encapsulation
look like?  In both directions...



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


[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.



...
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".



...
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


[major] Most Normative references should be listed, please add
draft-ietf-pim-p2mp-policy-ping, RFC6428, RFC7880, RFC8287, RFC8402,
RFC9524, and RFC9612.



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



...
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.



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.



...
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.

[EoR-12]