Re: [spring] Comments on draft-ietf-spring-bfd-07

[linchangwang <[e-mail]>]

Hi All,

Path  inconsistency  may cause false positive issue.
When we have a high SLA requirement for the seglist path in an SR policy, and there is bi-directional symmetric traffic forwarding path present,
we need to ensure that there is BFD bidirectional path consistency. This helps to avoid any false BFD DOWN events.
To the issue, The consistency of  forward and reverse path of the same session should be guaranteed.

S-BFD provides a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale network, with supporting
verification on reflector.
U-BFD defined in [I-D.ietf-bfd-unaffiliated-echo] can effectively reduce the device equipment.

https://datatracker.ietf.org/doc/draft-lin-bfd-path-consistency-over-sr/
-This draft【draft-lin-bfd-path-consistency-over-sr】 describes how S-BFD and U-BFD to achieve the bidirectional path consistency of packet
when monitoring SR policy.

  Path Segment is used to identify an SR path
       1) In SR for MPLS,   is defined in [draft-ietf-spring- mpls-path-segment]
       2) In SR for IPv6,   is defined in [draft-ietf-spring-srv6-path-segment]
[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.

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)  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 of U-BFD.

Both SR-MPLS and SRv6 can utilize the path-segment and reverse path-segment mechanism to enable SBFD and U-BFD detection for the seglist path in an SR policy,
thereby ensuring the bidirectional path consistency.

Thanks,
Changwang



From: spring [mailto:[e-mail]] On Behalf Of Gyan Mishra
Sent: Sunday, July 30, 2023 1:08 PM
To: Greg Mirsky
Cc: Ketan Talaulikar; SPRING WG
Subject: Re: [spring] Comments on draft-ietf-spring-bfd-07

Hi Greg

I think this is a highly valuable draft for operators to to be able to monitor the SR policy SID list being instantiated by the BSID binding of candidate path to forwarding plane. I think this could be applicable to SRv6.

RFC 9256 SR Policy defines a unidirectional candidate path with 2-tuple value value <color,endpoint> instantiated via PCEP, BGP, local policy.

I think it’s a great idea to use S-BFD or maybe even multi hop BFD RFC 5883 to monitor the BFD session unidirectionally BFD async mode similar to the drafts  S-BFD bidirectionally.   The caveat with monitoring the bidirectional Co-routed path is per the draft  to use RFC 5884 method to bootstrap LSP Ping FEC binding to BFD session to monitor the LSP.

As the standard MPLS data plane is based on unidirectional LSP as well SR-MPLS and SR Policy Candidate path SID List is a unidirectional LSP to be monitored, what is the reason to monitor the BFD control packets bidirectionally.

BFD async mode is one way control packets where echo the packets are looped requiring bidirectional LSP along the entire path.

Is the monitoring of the reverse parh for special use cases such as for transport networks bidirectional Co-routed path RFC 7551 RSVP-TE extension for bidirectional Co-routed paths or maybe some other scenario.

Another possible method to monitor the return path is using the path SID draft below as opposed to BSID.

MPLS path Segment
https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment

SR Policy path Segment for bidirectional paths
https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment

Kind Regards

Gyan

On Wed, Jul 26, 2023 at 1:42 PM Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ketan,
thank you for your clarification in the expedient follow-up note. I have a question about the use of the B-SID. As I understand the processing, B-SID would be replaced by the associated segment list in the forwarding plane. Is that right? If it is, it seems like the packet is not identified as the BFD Control message and, consequently, not validated according to RFC 7880. Further, the packet that would be returned to SBFDInitiator would be the same packet that it transmitted. Thus, it seems to me, the procedures defined in RFC 7880 are not followed. Am I missing something?

Regards,
Greg

On Wed, Jul 26, 2023 at 10:30 AM Ketan Talaulikar <[e-mail]<mailto:[e-mail]>> wrote:
Hello All,

Sharing the comments made at the mike in today's session to the list as we ran out of time:

1) The "path" to be monitored for SR Policy should be the Segment List and not Candidate path. Perhaps https://www.rfc-editor.org/rfc/rfc9256.html#section-2.13 will clarify the model for SR Policy. The RFC section 2 explains in more detail.

2) SR Policy construct is unidirectional and hence the issue of packet drops in reverse path is applicable to all forms. There may not always be a reverse path.

3) If there is a need to specify a reverse path, the same can be done without the need for LSP ping bootstrap overhead. E.g., https://datatracker.ietf.org/doc/html/draft-ali-spring-bfd-sr-policy-10#section-3.3 - there are also other mechanisms like using the BSID of the reverse path to return.

Thanks,
Ketan

_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring
--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
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!