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

[Greg Mirsky <[e-mail]>]

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

>
>
> 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：
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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/>.

> 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.

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

>
>
> 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!
>