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

[Greg Mirsky <[e-mail]>]

Hi Alvaro,
thank you for you detailed and helpful feedback. I'm working on addressing
your comments and resolving outstanding concerns.

Regards,
Greg

On Wed, Feb 19, 2025 at 1:30 AM Alvaro Retana <[e-mail]>
wrote:

> On February 1, 2025 at 6:43:12 PM, Greg Mirsky wrote:
>
>
> Greg:
>
> Hi!
>
> Please see some responses inline.
>
> Thanks!
>
> Alvaro.
>
>
> ...
> > > 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?
>
> No, I don't think so.
>
> This is an experimental document that aims to experiment in the field.
> Asking for operator feedback/experiences would be something to be done once
> the experiment is over.
>
> Also, not all options are part of the experiment, so I would expect
> operators to have more experience with them, which would bring up the
> question of why we need another option.
>
>
> I would prefer it if you (authors) provided technical guidance instead.
> After all, this document proposes various options.
>
> Note that my comment is "minor".  I can live with the experience being
> part of the experiment.
>
>
>
> ...
> > > 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] 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?
>
> I guess it's a matter of interpreting where an SR Policy starts/ends.
>
> I'm thinking of it from the point of view of the definition in rfc8402:
>
>    5.  Binding Segment
>
>    In order to provide greater scalability, network opacity, and service
>    independence, SR utilizes a Binding SID (BSID).  The BSID is bound to
>    an SR Policy, instantiation of which may involve a list of SIDs.  Any
>    packets received with an active segment equal to BSID are steered
>    onto the bound SR Policy.
>
> This text implies (at least to me) that the BSID signals the entry into an
> SR Policy, which means that (for this draft) is the end of the previous SR
> Policy.
>
> IMO, it is important to clarify how a BSID is considered in this draft.
> If considered as you explained, then please add a sentence about a BSID not
> being able to be the last segment...or something to that effect.
>
>
>
> ...
> > > 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.
>
> In this case, none of these suggestions (including mine!) work.
>
> I looked at rfc5884 again. In §7 (Encapsulation), it says that the egress
> "MAY be routed based on the destination IP address...or...MAY be
> encapsulated in an MPLS label stack".  While I think your interpretation
> (using MUST) is what was probably meant by the two MAYs, all suggestions
> use text that differs from the original -- and we shouldn't reinterpret or
> respecify something that is specified elsewhere.
>
> Suggestion>
>
>    For the BFD over MPLS LSP case, the egress LER MUST send BFD
>    Control packets to the ingress LER as specified in [RFC5884].
>
>
>
> ...
> > > [nit] s/(...)/
> > GIM>> I couldn't find it.
>
> The text in parenthesis was: "(to be assigned by IANA as requested in
> Section 8.1)”—you don't need it.
>
>
>
> ...
> > > [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.
>
> The range doesn't need to be changed -- you can keep 16384-31739.
>
> Note that the 31740-31743 range is reserved for "Experimental Use",
> meaning a value will not be assigned.  IOW, people are free to use any
> value for experiments.  Even though this is an Experimental document, we
> want interoperability, so the value must be known/assigned.
>
> You could also request a value from the 31744-32767 range (First Come
> First Served), up to you.
>
>
>
>
> > > [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?
>
> I'm not thinking of future-defined sub-TLVs; what about the already
> defined ones?
>
> The question is because the definition of the BFD Reverse Path TLV in
> rfc9612 allows for "zero or more...non-multicast Target FEC Stack
> sub-TLVs", and several are already defined.  IOW, what happens if another
> path is indicated along with the Non-FEC Path TLV?
>
> I'm not asking about all possible combinations (that should have been
> specified in rfc9612).  I'm just asking about the combination of the
> Non-FEC Path TLV and other existing TLVs.
>
> See more below...
>
>
> > >
> > >
> > >
> > > 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/(...)/
>
> Same as before: the text in parenthesis is not needed.
>
>
>
> ...
> > > [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.
>
> Yes, it carries a single entry, but I'm asking about using several
> sub-TLVs.  There's nothing that limits the number of TLVs so that it could
> describe the path the same way as one Non-FEC Path TLV.  The question above
> was: If multiple Type-A Segment Sub-TLVs can be used, isn't that the same
> as a single Non-FEC Path TLV?
>
>
>
> No, they're not mutually exclusive, or at least no place says that.  Note
> that rfc9612 allows "zero or more sub-TLVs", and rfc9716 doesn't say
> anything about the sub-TLVs not being allowed with others.
>
> Even if the TLVs were mutually exclusive, the behavior if both are present
> is not specified anywhere.
>
> For this document, I think that you don't want the Non-FEC Path TLV to
> interact with other sub-TLVs given the potential confusion and
> inconsistency.  If that is true, you need to say something in the draft.
>
>
>
>
>
> > > 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].
> ...
> > > [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].
>
> This text says what?  As I read it, it says that what was defined in
> rfc8287 applies to the context of rfc8287, which is not a false statement
> but also obvious and unnecessary.
>
>
>
>
>
> > > 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)
>
> You found *6.8.14*, not *6.18.4*. :-)
>
>
>
>
> ...
> > > 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.
> ...
> > 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.
>
> There's no "BGP-BFD Attribute" in rfc9026. I assume you meant the BGP BFD
> Discriminator attribute.
>
> The new paragraph is fine.
>
>
>
> ...
> > GIM>> AFAICS, draft-ietf-pim-p2mp-policy-ping is not the Normative, but
> > Informational reference.
>
> §5 reads: "...MAY use LSP Ping [I-D.ietf-mpls-p2mp-bfd] and
> [I-D.ietf-pim-p2mp-policy-ping]..."  Both drafts should be Normative
> references because they are associated with Normative behavior.
>
>