Hi Sasha, In general, the headend may choose the endpoint of SRv6 Policy or a user-specified address to be the tail-end address (details are described in Section 3). I think it also works for the single-Service-SID case you mentioned. Besides, additional tail-end address is not necessary in that case, because the BFD control packet already can reach the tail-end through the Service SID.
By the way, it is also called SRv6 BE Service when user data are forwarded through the SRv6 network by using a single Service SID. In most cases, SRv6 BE Service can be provided without SRv6 Policy. RFC9252 describes "To provide SRv6 service with best-effort connectivity, the egress PE signals an SRv6 Service SID with the BGP overlay service route. The ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID provided by the egress PE." And BFD is often used to monitor the Service SID or its Locator. But I would not deny that we can use SRv6 Policy consisted of a single Service SID to provide BE Service. In those cases, the encapsulation method in the draft can also work. Thanks, Mengxiao From: spring <spring-boun...@ietf.org> On Behalf Of Alexander Vainshtein Sent: Friday, November 11, 2022 5:33 PM To: linchangwang (RD) <linchangwang.04...@h3c.com> Cc: rtg-bfd WG <rtg-...@ietf.org>; spring <spring@ietf.org>; Greg Mirsky <gregimir...@gmail.com> Subject: Re: [spring] A question about Encapsulation of BFD for SRv6 Policy Hi all, I wonder whether the authors have considered the possibility in which he SRv6 policy is comprised of just the routable SRv6 Service SID with no SRH present in the data packets. Among other things, in this case the head-end node would not be aware of any specific address of the tail-end node, only of the address that represents the Service SID. My 2c, Sasha From: Rtg-bfd <rtg-bfd-boun...@ietf.org<mailto:rtg-bfd-boun...@ietf.org>> On Behalf Of linchangwang Sent: Thursday, November 10, 2022 6:36 AM To: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>; spring <spring@ietf.org<mailto:spring@ietf.org>> Cc: rtg-bfd WG <rtg-...@ietf.org<mailto:rtg-...@ietf.org>> Subject: [EXTERNAL] RE: A question about Encapsulation of BFD for SRv6 Policy Hi Greg, The differences between the SRH of user data and bfd packet: 1. The encapsulations of user data usually include a Service-SID in the SRH, but the encapsulations of BFD does not. 2. In order to make sure the BFD control packet can reach the tail-end, IPv6 address of the tail-end node may be added as Segment[0] in the SRH. When and why to add the tail-end address are described in section 2.1 & 2.3. 3. For BFD echo, IPv6 address of the headend needs to be added in the SRH, so that the packet can return to the headend. In spite of the above differences, both the SRH of user data and bfd packet contain the complete segment list of the SR Policy, and they will traverse the same set of nodes and links. Best regards, Changwang lin From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Greg Mirsky Sent: Tuesday, November 08, 2022 7:32 PM To: spring Cc: rtg-bfd WG Subject: A question about Encapsulation of BFD for SRv6 Policy Dear All, as suggested by the SPRING WG Chairs, I'm bringing the discussion to the mailing list. I think that it is also relevant and might be of interest to the BFD WG community. My questions at the mic were: · What is unique in the encapsulations of a BFD Control message described in the draft from encapsulations of user data in the respective scenarios? · And if encapsulation of a BFD Control message is different from the encapsulation of a data flow (SRv6 Policy) that is monitored by the BFD session, what mechanism ensures that BFD and data packets traverse the same set of nodes and links? Regards, Greg ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ 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! Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
