Re: [spring] Discussion on [draft-lin-bfd-path-consistency-over-sr]

[linchangwang <[e-mail]>]

Hi Greg,

Thank you for your careful comments.
My response can be found in line below, starting with the text [Changwang].

Thanks,
Changwang



From: Greg Mirsky [mailto:[e-mail]]
Sent: Tuesday, August 01, 2023 12:52 AM
To: linchangwang (RD)
Cc: SPRING WG; rtg-bfd WG
Subject: Re: [spring] Discussion on [draft-lin-bfd-path-consistency-over-sr]

Hi Changwang,
thank you for your prompt response to my comments at the IETF-117. I think that this draft is also relevant for the work of the BFD WG and I have invited its experts to the discussion. I agree with the base premise of the draft that it is essential to control the reverse path of an x-BFD session. But I also believe that such control is easier to realize for BFD sessions in Asynchronous mode, as defined in RFC 5880. Please find my notes below tagged GIM>>.

Regards,
Greg

On Mon, Jul 31, 2023 at 7:30 AM linchangwang <[e-mail]<mailto:[e-mail]>> wrote:

Hello Greg,

From minutes-117-spring/:
10:15 S-BFD Path Consistency over SRv6 (10 mins)
Presenter: Changwang Lin
draft-lin-sbfd-path-consistency-over-srv6<https://datatracker.ietf.org/doc/draft-lin-sbfd-path-consistency-over-srv6/>
Greg Mirsky: Current version of the WG draft about the U-BFD, U-BFD is only applicable to single hop.
        Not sure it is applicable to your scenario which has more than single link.
How this mapping between Segment List1 and Segment List2 occurs on a system (reflector or echo-reflector) that receives a BFD packet?
All the processing is in the forwarding plane, so in fact the BFD is not involved.
Joel: More details, complicated, so we need to take it to the mailing list.

Thank you for your comments ，here is my response：

1.      Regarding question 1: It is true that the current version of the [ietf-bfd-unaffiliated-echo] draft only specifies the single hop scenario.

However, it is worth noting that U-BFD can support multiple hops, for example, by setting the TTL to 64. Therefore, U-BFD can also be used to detect the seglist path in an SR policy.
GIM>> Let me quote from Section 2 of draft-ietf-bfd-unaffiliated-echo <https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/> :
   All
   Unaffiliated BFD Echo packets for the session MUST be sent with a
   Time to Live (TTL) or Hop Limit value of 255, and received with a TTL
   or Hop Limit value of 254, otherwise the received packets MUST be
   dropped [RFC5082].
I don't see how, as you suggest, a conformant U-BFD implementation can set TTL/Hop Limit to any value other than 255 or not drop the received packet if the value of its TTL/Hop Limit field is anything but 254. Or, perhaps you are planning to update the current U-BFD specification?

[Changwang] In actual U-BFD deployment, there are many multi-hop U-BFD application scenarios, such as SR-MPLS tunnels, GRE tunnels, VXLAN tunnels, SR Policy, and SRv6 Policy. In the implementation by vendors, BFD messages can typically be encapsulated within tunnels, and can be forwarded using SR-MPLS or SRv6, without modifying the TTL of the inner layer BFD messages. This ensures that the TTL of the BFD messages remains unchanged. For the scenario of SR Policy, by encapsulating the Segment List in the U-BFD echo packet, the U-BFD echo packet can be forwarded through multiple hops to the reflector, thus achieving detection of multi-hop. If the remote BFD system does not process Echo BFD, the value of the "Your Discriminator" field must be set to the discriminator assigned by the local BFD system to the given BFD session.Therefore, for SR-MPLS or SRv6, U-BFD is no longer limited to detecting one-hop neighbors. This document is also based on this to discuss how to specify the return path when detecting a remote reflector through multiple hops.



2.      Regarding question 2:
 [draft-ietf-idr-sr-policy-path-segment] extends BGP SR Policy to distribute SR policies with carrying Path Segment and bidirectional path
information. Through this extension, when distributing SR policy to the headend, reverse path information and path segment of segment list could be carried
together.
        For example：



[cid:image001.jpg@01D9C4B8.45E8C6D0]



[cid:image002.png@01D9C4B8.45E8C6D0]



















Using path segment and reverse path segment to establish a mapping table.
Using the mapping table to get segment list by reverse Path segment.

1) Regarding SBFD, at the reflection end, the reverse seglist can be obtained through the path-segment mechanism.
GIM>> As I understand RFC 7880, its goal is not to create any state related to SBFDReflector. On the other hand, mapping between a particular Path Segment SID and the Reverse Path Segment List does create such state and, as a result, defeats the idea of RFC 7880. At the same time, binding the reverse path of a BFD session in the Asynchronous mode in SR-MPLS can be easily achieved using, for example, MPLS LSP Ping extensions defined in draft-ietf-mpls-bfd-directed<https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/> and draft-ietf-spring-bfd<https://datatracker.ietf.org/doc/draft-ietf-spring-bfd/>.

[Changwang] This is the mapping mechanism of path-segment itself in [[draft-ietf-spring- mpls-path-segment] and [draft-ietf-spring-srv6-path-segment]. The path segment and mapping table are not only applicable to SBFD.
For the reflection endpoint, SBFD only adds processing that looks up the return path through path-segment, and does not add any additional overhead.The reflection endpoint of SBFD itself needs to look up the routing table, and now it does so by searching for the return path through path-segment.This does not add any additional SBFD states, it is just a change in the lookup method.
The document 【draft-ietf-mpls-bfd-directed 】only describes using MPLS PING to bring back the return path. This method is not suitable for SRv6. On the other hand, it only brings back the return path, without explaining how S-BFD uses it. However, with the path-segment uniformly assigned through BGP through the SR policy mechanism, the return path and path-segment can be obtained at the head-end, thereby simplifying SR Policy processing.
In Chapter 9 of the[ draft-ietf-spring-bfd], "Use of S-BFD in SR-MPLS," the S-BFD Reflector transmits BFD Control messages as IP/UDP packets, using available resilience mechanisms of the IP network. However, there is no return path consistency feature for S-BFD in this drafted document, and it does not support SRv6.


2) For U-BFD, the complete reverse segment list can be distributed to the head node along with the segment list.
This reverse segment list can be used to specify the return path for U-BFD. Consequently, the return path can be encapsulated at the head end.
GIM>> As I've noted earlier, I believe that U-BFD, as it is defined at this time, cannot be used in SRv6 as suggested in draft-lin-sbfd-path-consistency-over-srv6.
 [Changwang] It may be beneficial to create a separate document to explain the various tunnel application scenarios and provide encapsulation instructions for implementing multi-hop U-BFD.


3.      Regarding question 3：
By utilizing the extension for SR Policy defined in 【draft-ietf-idr-sr-policy-path-segment】:

1)  By using Path Segment and Segment-Based Forwarding (SBFD) to encapsulate and forward packets along a forward path, the path-segment is included in the encapsulation.At the reflector node, this path-segment information is used to lookup the reverse path-segment, which helps to ensure the bidirectional consistency of the seglist . This provides a means to implement SBFD detection with bidirectional path consistency requirements.

2)     As for U-BFD, since the complete return information has already been encapsulated at the head end, there is no need for additional BFD processing at the reflection system. The packet can simply be forwarded back along the return path.
In Summary, when encapsulating SBFD packets with the path-segment, BFD processing is required at the reflection end.
On the other hand, U-BFD packets are encapsulated with the complete reverse seglist and do not require the path-segment.
Therefore, U-BFD does not need any processing at the reflection end.
GIM>> I cannot agree with your suggestion that the remote end can be simply traversed by a U-BFD Control message. If that is the case, then I don't see how your implementation of U-BFD conforms to the specification (quoted above):
   All
   Unaffiliated BFD Echo packets for the session MUST be sent with a
   Time to Live (TTL) or Hop Limit value of 255, and received with a TTL
   or Hop Limit value of 254, otherwise the received packets MUST be
   dropped [RFC5082].
[Changwang] :
For multi-hop U-BFD encapsulation, the following examples show the encapsulation for MPLS and SRv6:
MPLS Encapsulation:  <eth><forwarding mpls stack><return mpls stack><ip><udp><bfd payload>
SRv6 Encapsulation:  <ipv6><forwarding srh><return srh><ipv6><udp><bfd payload>
By using these encapsulation methods, the TTL check for BFD can be maintained.

For more detailed encapsulation formats, please refer to https://datatracker.ietf.org/meeting/117/materials/slides-117-spring-bfd-path-consistency-over-sr-00.pdf.
Thanks again!


Thanks,
Changwang

-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!