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.
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
