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

[Greg Mirsky <[e-mail]>]

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