Hi Jeffrey,
Thank you for the comments, please see the reply inline starts with [FY#]. Cheers, Fan -----邮件原件----- 发件人: spring [mailto:spring-boun...@ietf.org] 代表 Jeffrey (Zhaohui) Zhang 发送时间: 2021年3月26日 3:19 收件人: Gengxuesong (Geng Xuesong) <gengxues...@huawei.com>; spring@ietf.org; Rishabh Parekh (riparekh) <ripar...@cisco.com>; Arvind Venkateswaran (arvvenka) <arvve...@cisco.com> 主题: [spring] Comments on draft-geng-spring-sr-redundancy-protection Hi Xuesong, Mach, Fan, Some comments/questions on the proposal. 1. We don't need an additional "redundancy segment" for the replication semantics. Existing "replication segment" (draft-ietf-spring-sr-replication-segment) can be used as is, especially for the scenario where the original header already carries (FI, SN) information. ------[FY1]: three considerations here: a). For the scenario you mentioned, that is correct, redundancy segment and replication segment share a common behavior of "packet duplication". The significant difference between two segments is the behavior of adding FI and SN. Unfortunately, there is no application in SRv6 required to carry (FI,SN) information in IPv6 header, which results in a more common scenario is where the original packet doesn't carry (FI, SN). So the current design of redundancy segment is based on this scenario. b). Even though IPv6 flow label could be encapsulated in header, it is used for ECMP or fragmentation, redundancy protection cannot simply reuse it since flow ID allocation has dependency on the merging node capability. c). In protocol design, it is important to maximally reuse the existing implementation. However, instantiation of a segment is a different story. In RFC8986, there are 14 End behaviors and 4 headend behaviors defined. We understand the principle here is to keep the semantics of a segment and further functions definition neat to make the segment routing forwarding clear and efficient. To enhance the replication segment to support redundancy segment seems quite an opposite methodology. 2. Even for the scenario where the (FI, SN) information needs to be added by the redundancy node, the existing "replication segment" can be enhanced to add the (FI, SN) information. -----[FY2]: Replication segment provides P2MP replication with target of supporting multicast service, and redundancy segment aims to provide redundant flow protection to URLLC services. Adding (FI, SN) doesn’t bring value to multicast services, and having the stitching capability of replication on redundancy node seems a waste and unpractical to URLLC service. Twisting them together in one segment results in a complicated function, where maybe only one type of service is required on the node. 3. I wonder why (FI, SN) information is added as a TLV in the SRH. Would it be better to use DOH? -----[FY3]: If the (FI,SN) is encapsulated in type of TLV, both SRH and DOH are feasible. Actually (FI,SN) information is only meaningful to merging node, putting them in the arg part of replication segment doesn't help. For #1, and #2, reusing/enhancing existing replication segment has the following benefits: a. Reduce protocol/implementation work b. Reduce the amount of state in the network (the same P2MP tunnel can be used for both multicast traffic and unicast redundancy) b) can be achieved even with #2 (redundancy node needs to add (FI, SN) information): for SRv6, the semantics of adding (FI, SN) can be indicated by the arg part of the replication SID and for SR-MPLS it can be indicated by an additional label in front of the replication sid label. If using an addition label is a concern, then indeed a single label can be used to indicate both "add FI/SN information" and "replicate", but still the replication semantics can still be set up using the replication segment infrastructure. For SR-MPLS, where would you put the (FI, SN) information? Seems that GDFH (draft-zzhang-intarea-generic-delivery-functions) is a good option and that can be used for SRv6 as well (anything in DOH that is actually independent of IP could be extracted out to GDFH). -----[FY4]: For SR-MPLS, currently the authors plan to keep consistent with specification in RFC8964. The original intention of this draft is to provide a PREOF solution in SR data plane to DetNet. What's why the draft is discussed first in DetNet then comes to SPRING. And FYI, DetNet MPLS data plane uses a separate service label (S-Label) and PW MPLS Control Word [RFC4385] to carry FI and SN. Thanks. Jeffrey Juniper Business Use Only _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
