Hi Sandy, Thank you for the review and comments, really appreciate it. Please see my feedback inline [Changwang].
Thanks, Changwang 发件人: rtgwg <[email protected]> 代表 [email protected] 发送时间: 2024年2月29日 16:49 收件人: [email protected] 抄送: [email protected] 主题: Re: FW： New Version Notification for draft-liu-rtgwg-path-aware-remote-protection-00.txt Hi Yisong, Changwang, Mengxiao, After reading this draft, I think it's an interesting topic. I have some comments here: 1. Where is the function deployed, only leaf node or both of leaf and spine node? [Changwang] In the path-aware remote protection, there are three types of roles for a router: o Remote repair node: It has the repair path(s) and provides the remote protection function. o Local detection node: It is adjacent to the failure and detects the failure first. Then, it sends failure notification messages to the remote repair node. o Intermediate node: It exists only if there are multiple hops between the remote repair node and the local detection node. It helps deliver the failure notification messages from the local detection node to the remote repair node. Therefore, both leaf and spine nodes need to be deployed and work together. For example, the spine node can take on the role of local detection, while the leaf node functions as the remote repair. 1. According the example you mentioned in section 3.3, in case the link between remote spine node and leaf node broken, how does the remote spine node know which spine/leaf node should be notified, and which path should be carried in the notification message? [Changwang] This involves several key issues: a) Forwarding: The next-hop of the route needs to include path information, as shown in Figure 4 of section 3.1. b) Control plane: Control plane routing protocols are associated with devices along the path. For instance, when BGP advertises a route, it carries information about the devices along the path. c) Fault notification: When a fault occurs, the notification message should carry information about the remote device, corresponding to the path information in the next-hop route. Typically, in a two-tier architecture, the upper-level node has a protection path, and the fault notification message is sent to the upstream node or triggered by traffic, which can be notified through the incoming interface of the traffic. We can further discuss this in more depth. 1. The topology depolyed in DC which used for AI/HPC may be 3-level or 5-level fat-tree, if there are many pods in the DC, there are plenty of routes and paths in the network, right? How do you consider the scaling problem? [Changwang] In a multi-tier architecture, the upper-level node typically has ECMP protection paths, so the notification message only needs to traverse one hop. If the upper-level node does not have a protection path, it can continue to propagate the notification upward. Thanks, Sandy <http://www.zte.com.cn/> <http://www.zte.com.cn/> Original From: YisongLiu <[email protected]<mailto:[email protected]>> To: rtgwg <[email protected]<mailto:[email protected]>>; Date: 2024年02月26日 08:47 Subject: FW： New Version Notification for draft-liu-rtgwg-path-aware-remote-protection-00.txt _______________________________________________ rtgwg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg Hi Everyone, We have just submitted a draft on the rapid switchover of remote fault perception. The link for this draft is: https://datatracker.ietf.org/doc/draft-liu-rtgwg-path-aware-remote-protection/ The current main protection technologies include local protection through FRR, such as TI-LFA protection, and end-to-end protection through multi-path protection. In specific network scenarios, such as a spine-leaf two-layer architecture, TI-LFA cannot be deployed, and even if it is deployed, traffic will still loop during a fault. Therefore, this draft proposes a mechanism for rapid switchover that is aware of remote paths. By associating the next hops with remote path information at the forwarding plane, the local end can be quickly notified to switch in the event of remote fault, achieving fault switchover in milliseconds, or even microseconds. We welcome your feedback. If you have any questions or comments, please feel free to let us know. Best Regards Yisong 发件人: internet-drafts<mailto:[email protected]> 时间: 2024/02/23(星期五)15:27 收件人: Changwang Lin<mailto:[email protected]>;Mengxiao Chen<mailto:[email protected]>;Yisong Liu<mailto:[email protected]>; 主题: New Version Notification for draft-liu-rtgwg-path-aware-remote-protection-00.txt A new version of Internet-Draft draft-liu-rtgwg-path-aware-remote-protection-00.txt has been successfully submitted by Mengxiao Chen and posted to the IETF repository. Name: draft-liu-rtgwg-path-aware-remote-protection Revision: 00 Title: Path-aware Remote Protection Framework Date: 2024-02-23 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-liu-rtgwg-path-aware-remote-protection-00.txt Status: https://datatracker.ietf.org/doc/draft-liu-rtgwg-path-aware-remote-protection/ HTMLized: https://datatracker.ietf.org/doc/html/draft-liu-rtgwg-path-aware-remote-protection Abstract: This document describes the framework of path-aware remote protection. The IETF Secretariat ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ 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!
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
