[mpls] Re: [spring] Re: Shepherd review for draft-ietf-spring-bfd-10

[[e-mail]]

Thank you Ketan!
Your explanation is clear to me.

Cheers,
Xiao Min


Original


From: KetanTalaulikar <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年10月24日 16:05
Subject: [spring] Re: Shepherd review for draft-ietf-spring-bfd-10


Hi Xiao Min,
 
Yes, there is a state corresponding to the Path SID on the tailend of
an SR Policy that ties it to the context of a specific SR Policy
Segment List. The label associated with the PSID belongs to the
tailend (i.e. endpoint) and so for any SR Policy that is using PSID
results in state instantiation (including the PSID label) on the
tailend (even if the use-case was only unidirectional SR Policy).
 
This is per RFC9545 section 2.
 
Thanks,
Ketan
 
On Thu, Oct 24, 2024 at 7:04 AM <[e-mail]> wrote:
> 
> Hi Ketan,
> 
> 
> Pardon me to chime in. Cc MPLS mailing list.
> 
> I'm discussing with Greg on draft-ietf-mpls-spring-lsp-ping-path-sid, attempting to address his concern on whether there is a state of Path SID on the endpoint.
> 
> Your help is much appreciated. Please see inline.
> 
> >> 
> >> < major > SR Policy scale is generally expected to be higher than RSVP-TE
> >> tunnels since the state is only present on the headend. Then we have CPs and
> >> SLs. Can the draft cover the scalability aspects of the different BFD flavors?
> > 
> > GIM>> AFAICS, draft-ietf-mpls-spring-lsp-ping-path-sid expresses a different point of view regarding the expectation of where SR Policy information is maintained. As I understand it, that draft expects the endpoint of an SR Policy to know all the details and associations of the SR Policy.
> 
> KT> That is correct but Path SID is not applicable for all types of SR
> Policies but for a limited subset of use-cases. I believe the use of
> BFD is more widespread.
> 
> [XM]>>> I was told that your answer is still not explicit enough. Could you please be more explicit on whether there is a state of Path SID on the endpoint?
> 
> 
> Thanks!
> 
> Xiao Min
> 
> Original
> From: KetanTalaulikar <[e-mail]> 
> To: Greg Mirsky <[e-mail]>;
> Cc: [e-mail] <[e-mail]>;SPRING WG <[e-mail]>;spring Chairs <[e-mail]>;
> Date: 2024年10月22日 00:42
> Subject: [spring] Re: Shepherd review for draft-ietf-spring-bfd-10
> Hi Greg/Authors,
> 
> Thanks for the document update posted. It addresses many of the
> comments and includes some of the suggestions made. I've left out the
> parts that have been addressed.
> 
> Since this document has not yet gone through a WGLC, I will leave some
> of the open points below for the WG Chairs to determine which of those
> are perhaps more appropriate to consider as part of the WGLC so as to
> seek WG inputs.
> 
> Please check inline below for responses with KT.
> 
> One new concern (not previously reported): The document was turned
> into experimental status because one part in there was using an
> experimental BFD extension. However, the IANA section is asking for
> creation of a new registry that has allocations from standards action.
> Even the allocation from Return Codes registry is from the standards
> action block - perhaps it should be from the other two blocks?
> 
> On Thu, Aug 29, 2024 at 5:01 AM Greg Mirsky <[e-mail]> wrote:
> > 
> > Hi Ketan,
> > thank you for your detailed review and thoughtful comments. Please find my notes below tagged GIM>>. Attached, please find the new working version and diff that highlights updates.
> > 
> > Regards,
> > Greg
> > 
> > On Tue, Jul 16, 2024 at 6:35 PM Ketan Talaulikar <[e-mail]> wrote:
> >> 
> >> Hello All,
> >> 
> >> Please find below the shepherd review for this document as asked for by the chairs.
> >> 
> >> Thanks,
> >> Ketan
> >> 
> >> 
> >> Major:
> >> 
> >> 1) Alignment to SR Policy [RFC9256] terms is needed (e.g., what is
> >> monitored is individual SLs instead of "tunnels").
> > 
> > GIM>> Thank you for the useful reference. Updated terminology accordingly.
> >> 
> >> The operations and
> >> interactions between the SR Policy framework and BFD is required to be specified -
> >> somewhat on similar lines as what RFC5882 did. SR Policy as defined in [RFC9256] consists
> >> of candidate paths which in turn contains one or more segment list. The BFD
> >> monitoring is done for each individual segment list. When the BFD detects that
> >> a segment list is down, it is considered invalid and taken out from the
> >> forwarding. When all segment lists in a CP are down, then the CP is down and
> >> another CP path would need to be evaluated. This also means that, when
> >> enabled, BFD validation augments the CP validation as
> >> specified in section 5 of RFC9256.
> > 
> > GIM>> How a client application, SR restoration in this case, is reacting to a defect detection is, of course, a question worthy of a discussion. But I am not sure that such discussion is in the scope of this draft. As I recall, the SPRING WG has not requested that it will be included. The applicability of BFD in the SR-MPLS network is discussed in the draft. I imagine that use of BFD in SR restoration is equally applicable in SRv6 network and, it seems like, might be more in place in a draft discussing SR resiliency and restoration in SRv6 and SR-MPLS networks.
> 
> KT> I agree that this aspect is applicable to SR Policies for both
> MPLS and SRv6 dataplanes. However, there isn't a specification today
> that covers it that can be referenced in this document. I think it
> should be fairly simple to add some text (on lines of suggestions
> provided above) so this document can progress. If not, it might be
> challenging to proceed. I will leave this call to the Chairs and the
> WG.
> 
> >> 
> >> 
> >> 2) There is no Target FEC stack defined for Segment Lists for SR Policy.
> > 
> > GIM>> AFAICS, draft-ietf-mpls-spring-lsp-ping-path-sid defines three Target FEC sub-TLVs:
> > 
> > SR Policy's Path Segment Identifier (PSID)
> > SR Candidate Path's PSID
> > SR Constituent List's PSID
> 
> KT> Yes, there are FEC definitions specified for several of the
> SR-MPLS segments - individually. I'll note that there is no FEC
> defined for Binding SID (BSID).
> 
> > 
> > These, in my opinion, would be helpful if the egress endpoint BFD system had information to validate Target FEC that includes any of these new sub-TLVs. I might be missing something, but SR Policy Path, SR Candidate Path, and SR Constituent List are intended for a SR Policy's headend, not the endpoint. If that is correct, then other sub-TLVs should be used. I believe that  Target FECs defined in RFC 8287, draft-ietf-pim-p2mp-policy-ping can be used to validate the path. Furthermore, procedures defined in draft-ietf-mpls-egress-tlv-for-nil-fec are also applicable to BFD bootstrapping using MPLS LSP ping.
> 
> KT> Again, these are all for individual segments of different types. I
> am referring to the Segment List as a whole and that there is no
> Target FEC defined for it and we are relying on using the Target FEC
> for the last segment. How does this work if the last segment is a BSID
> that gets expanded into another list of segments?
> 
> >> 
> >> Something that carries the < Headend, Endpoint, Color, <CP identifiers>, < SL
> >> identifiers/stack> > so that the egress LER can setup a BFD control session context
> >> for each of the segment lists of an SR Policy.
> > 
> > GIM>> What do you see as the benefit of an egress LER maintaining additional context per BFD session?
> 
> KT> We don't want to add context on the egress LER. What I am missing
> is a discussion that specifies that the Headend of the SR Policy needs
> to start LSP ping bootstrap process for each of the SLs (using the
> Target FEC TLV of its final segment) and then maintain the context for
> each of the SLs and the CP. See also (1) above. And, while using the
> final segment's Target FEC would work in many cases, I am not sure if
> it is robust enough for all cases - refer to my previous comment.
> 
> >> 
> >> Note that the egress LER can be
> >> the endpoint for a large number of SR Policies from multiple headends and each
> >> of these SR Policies can have multiple CPs and in turn multiple SLs. So, how
> >> is LSP Ping able to bootstrap the BFD control session for each of these
> >> individual SLs on the Egress LER?
> > 
> > GIM>> RFC 5884 doesn't impose any limit on the number of BFD sessions over an LSP between two BFD systems. In other words, multiple BFD sessions can be bootstrapped for the same Target FEC. Do you see any obstacle that would not allow the same behavior for a segment list in SR-MPLS?
> 
> KT> No obstacles - in fact all SLs will end on the same endpoint
> (tailend) so when there are multiple SLs, it is normally to expect
> multiple BFD sessions from the same headend to the tailend. I hope my
> previous responses have clarified my query.
> 
> >> 
> >> 
> >> Editorial:
> >> 
> 
> <snip> 
> 
> >> 
> >> 
> >> 14  Bidirectional Forwarding Detection (BFD) in Segment Routing Networks
> >> 15                          Using MPLS Dataplane
> >> 
> >> < major > The title should be corrected as BFD for SR Policies ?
> > 
> > GIM>> I think that the WG agreed with the existing title.
> 
> KT> The entire document is focussed on specification on BFD operations
> for SR Policies and not about BFD for individual SR segment types. If
> the intention is the latter, then perhaps this needs to be covered in
> the document.
> 
> <snip > 
> 
> >> 
> >> 289 5.  BFD Reverse Path TLV over Segment Routed MPLS Tunnel with Dynamic
> >> 290    Control Plane
> >> 
> >> 292   When Segment Routed domain with MPLS data plane uses distributed
> >> 293   tunnel computation BFD Reverse Path TLV MAY use Target FEC sub-TLVs
> >> 294   defined in [RFC8287].
> >> 
> >> < major > Is this really required? Does it not complicate things at both
> >> ends, why not just use the label stack directly in this case as well ?
> > 
> > GIM>> I consider that a matter of choice of an implementor and, subsequently, an operator.
> 
> KT> Perhaps we want to recommend the easier/simpler option as a MUST
> and the other one as a MAY? This helps ensure that when there are many
> options, implementers know which one is mandatory for
> conformance/interop and the others are optional.
> 
> <snip> 
> 
> >> 
> >> 342 8.  Use of Echo BFD in SR-MPLS
> >> 
> >> 344   Echo-BFD [RFC5880] can be used to monitor a segment list of the
> >> 345   particular SR Policy between the local and the remote BFD peers.  As
> >> 346   defined in [RFC5880], the remote BFD system does not process the
> >> 347   payload of an Echo BFD.  Thus it is the local system that
> >> 348   demultiplexes the Echo BFD packet matching it to the appropriate BFD
> >> 349   session and detects missing Echo BFD packets.  A BFD Control packet
> >> 350   MAY be used as the payload of Echo BFD.  This specification defines
> >> 351   the use of Echo BFD in SR-MPLS network with BFD Control packet as the
> >> 352   payload.  The use of other types of Echo BFD payload is outside the
> >> 353   scope of this document.  Because the remote BFD system does not
> >> 354   process Echo BFD, the value of the Your Discriminator field MUST be
> >> 355   set to the discriminator the local BFD system assigned to the given
> >> 356   BFD session.  My Discriminator field MUST be zeroed.  Authentication
> >> 357   MUST be set according to the configuration of the BFD session.  To
> >> 358   ensure that the Echo BFD packet is returned to the sender without
> >> 359   being processed, the sender MAY use a Binding SID (BSID) [RFC8402]
> >> 360   that has been bound with the SR Policy that ensures the return of a
> >> 361   packet to that particular node.  A BSID MAY be associated with the SR
> >> 362   Policy that is the reverse to the SR Policy programmed onto the BFD
> >> 363   Echo packet by the sender.
> >> 
> >> < major > Could you describe how the encapsulation of the BFD packet is done at the
> >>  sender along with this BSID for the return path?
> 
> KT> Looks like this one was missed?
> 
> >> 
> >> 365 9.  Use of S-BFD in SR-MPLS
> >> 
> >> 367   Seamless BFD (S-BFD), defined in [RFC7880], maintains essential
> >> 368   characteristics and elements of the base BFD mechanism described in
> >> 369   [RFC5880] with a lighter approach to instantiating a BFD session
> >> 370   between BFD peers.  Similar to the BFD Asynchronous mode, S-BFD is
> >> 371   capable of monitoring a segment list of a p2p SR Policy.
> >> 
> >> 373   Considering that a particular SR Policy can include multiple
> >> 374   candidate paths, which, in turn, have one or more segment lists, it
> >> 375   could be beneficial to monitor each segment list independently.  To
> >> 376   achieve that, S-BFD Reflector advertises My Discriminator value.
> >> 377   Then, the S-BFD Initiator uses the advertised My Discriminator value
> >> 378   as Your Discriminator value in the BFD Control messages transmitted
> >> 379   over the segment list of the SR Policy.  Furthermore, the S-BFD
> >> 380   Initiator assigns a unique My Discriminator for each S-BFD session
> >> 381   monitoring a segment list.  S-BFD Reflector transmits BFD Control
> >> 382   messages as IP/UDP packets, taking advantage of the available
> >> 383   resilience mechanisms of the IP network.  From that point, to
> >> 384   minimize the detection of failures in the IP network that do not
> >> 385   affect the monitored segment list, it is reasonable not to use defect
> >> 386   detection intervals that are close to the IP network repair time.
> >> 387   Instead, having an S-BFD detection interval three times longer than
> >> 388   the IP network repair time is practical.
> >> 
> >> < major > Is this aspect for return path not relevant to all forms of BFD when
> >> using an IP return path? Why is it only in this particular section?
> > 
> > GIM>> RFC5880-style BFD allows for negotiating the frequency of BFD control packets. S-BFD avoids the negotiation phase. Do you believe that the text is not technically accurate?
> 
> KT> Two points here. (a) there is no need to negotiate the frequency
> of BFD in S-BFD since it is decided by the headend/originator and (b)
> this aspect of the interval being larger than FRR is applicable for
> other forms of BFD in general.
> 
> >> 
> >> 
> >> 
> >> < major > Perhaps text can be picked from
> >> https://datatracker.ietf.org/doc/html/draft-ali-spring-bfd-sr-policy-10 that
> >> covers the SBFD operations in greater detail.
> > 
> > GIM>> It appears that the SPRING WG in the WG LC accepted the document and the scope of coverage of S-BFD.
> 
> KT> The WGLC is yet to happen.
> 
> >> 
> >> 
> >> < major > There are multiple BFD flavors described but there isn't a section
> >> that covers the pros/cons of their usage and applicability. Is that something
> >> that could be added?
> > 
> > GIM>> Comparing the defect detection methods is an operator's choice and is outside the scope of this document.
> 
> KT> Whenever we present multiple options, I've seen someone asking for
> any recommendations for operators or some operational considerations.
> 
> >> 
> >> 
> >> < major > SR Policy scale is generally expected to be higher than RSVP-TE
> >> tunnels since the state is only present on the headend. Then we have CPs and
> >> SLs. Can the draft cover the scalability aspects of the different BFD flavors?
> > 
> > GIM>> AFAICS, draft-ietf-mpls-spring-lsp-ping-path-sid expresses a different point of view regarding the expectation of where SR Policy information is maintained. As I understand it, that draft expects the endpoint of an SR Policy to know all the details and associations of the SR Policy.
> 
> KT> That is correct but Path SID is not applicable for all types of SR
> Policies but for a limited subset of use-cases. I believe the use of
> BFD is more widespread.
> 
> >> 
> >> 
> >> 
> >> 
> >> 390 10.  IANA Considerations
> >> 
> >> 392 10.1.  Non-FEC Path TLV
> >> 
> >> 394   IANA is requested to assign new TLV type from the from Standards
> >> 395   Action range of the registry "Multiprotocol Label Switching
> >> 396   Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters -
> >> 397   TLVs" as defined in Table 1.
> >> 
> >> 399               +=======+==================+===============+
> >> 400               | Value | TLV Name         | Reference     |
> >> 401               +=======+==================+===============+
> >> 402               |  TBD1 | Non-FEC Path TLV | This document |
> >> 403               +-------+------------------+---------------+
> >> 
> >> 
> >> < minor > I note that there is an implementation reported and in production by a vendor while
> >> code points are still not allocated. Could you please get this clarified and if there is already some
> >> code point being squatted upon? I couldn't find the early allocation as indicated in the implementation
> >> report section.
> > 
> > GIM>> Thank you for your question. As in RFC 9612, the allocation is requested from 16384-31739 range rather than from the Standard Action range.
> 
> KT> Perhaps those implementers should ask for allocation of the code
> point that they used ASAP? And then the document asks for the
> codepoint that was used by the implementation?
> 
> < snip > 
> 
> > 
> >> 507   - Implementation experience: Appreciate Early Allocation of values
> >> 508   for Non-FEC TLV and Segment Routing MPLS Tunnel sub-TLV (using
> >> 509   Private Use code points).
> >> 
> >> 511   - Contact information: Qian Xin [e-mail]
> >> 
> >> 513   - The date when information about this particular implementation was
> >> 514   last updated: 12/16/2019
> >> 
> >> < minor > The implementation reference is to a very old document version that has
> >> gone through several changes. Is the "complete" coverage accurate? Please consider
> >> polling the WG to get an updated implementation status for the various BFD flavors/sections
> >> in this document.
> > 
> > GIM>> The Implementation Status section conveys information about the deployment the Non-FEC TLV:
> >    - Implementation experience: Appreciate Early Allocation of values
> >    for Non-FEC TLV and SR Policy's Segment List sub-TLV (using Private
> >    Use code points).
> > Other flavors of BFD are outside the scope of this section.
> 
> KT> The implementation section should cover the entire document and
> not specific sections. I would assume that the WG chairs will poll the
> WG for implementation status of individual features and this gets
> updated in the document per SPRING WG policy (even if it says - "no
> known implementation").
> 
> < end of responses > 
> 
> _______________________________________________
> spring mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 
> 
 
_______________________________________________
spring mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]