Hi Rishabh, Thanks for chiming in on the End behavior point!
Hi Fan, Please see zzh2 below for other points. From: Rishabh Parekh <risha...@gmail.com> Sent: Wednesday, April 14, 2021 3:10 PM To: Yangfan (IP Standard) <shirley.yang...@huawei.com> Cc: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Gengxuesong (Geng Xuesong) <gengxues...@huawei.com>; Rishabh Parekh (riparekh) <ripar...@cisco.com>; Arvind Venkateswaran (arvvenka) <arvve...@cisco.com>; spring@ietf.org Subject: Re: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection [External Email. Be cautious of content] Fan, Zzh> RFC 8986 does specify additional flavors of End and End.X function with USP, PSP and USD behaviors which are modifications to base End and End.X function; exactly what we are proposing here – enhancing Replication Segment to add (FI,SN) when required. Fan>> can you explain more? I don’t see correlation between flavors and adding (FI,SN). Fan>> after seeing all these “if, then” shown above, I even feel more strongly to support separating two segments. ☺ In RFC8986, there is no single Endpoint behavior having such “if, then” structure to specify different functions. RP> What Jeffrey means is RFC 8986 already has a precedent of defining functionality, End and End.X, with slight modifications to basic behavior – these are the PSP, USP and USD variants. An implementation that supports these flavors has to have “if-then-else” logic to deal with active SIDs for End and End.X segments with different flavors. RP> We are proposing the same approach here; modify base Replication segment behavior to add (FI,SN) if required. Also note that the definition of Replication segment already has “if-then-else” built in to deal with decapsulation on a Leaf node, or replication to downstream nodes, or to do both on a Bud node. -Rishabh On Thu, Apr 8, 2021 at 6:25 AM Yangfan (IP Standard) <shirley.yang...@huawei.com<mailto:shirley.yang...@huawei.com>> wrote: Hi Jeffrey, Apology for being so late to reply. Please see inline starts with Fan>>. Cheers, Fan 发件人: spring [mailto:spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>] 代表 Jeffrey (Zhaohui) Zhang 发送时间: 2021年3月30日 5:06 收件人: Yangfan (IP Standard) <shirley.yang...@huawei.com<mailto:shirley.yang...@huawei.com>>; Gengxuesong (Geng Xuesong) <gengxues...@huawei.com<mailto:gengxues...@huawei.com>>; 'Rishabh Parekh (riparekh)' <ripar...@cisco.com<mailto:ripar...@cisco.com>>; 'Arvind Venkateswaran (arvvenka)' <arvve...@cisco.com<mailto:arvve...@cisco.com>>; spring@ietf.org<mailto:spring@ietf.org> 主题: Re: [spring] Comments on draft-geng-spring-sr-redundancy-protection Hi Fan, Please see zzh> below. From: Yangfan (IP Standard) <shirley.yang...@huawei.com<mailto:shirley.yang...@huawei.com>> Sent: Friday, March 26, 2021 11:58 PM To: Jeffrey (Zhaohui) Zhang <zzhang=40juniper....@dmarc.ietf.org<mailto:zzhang=40juniper....@dmarc.ietf.org>>; Gengxuesong (Geng Xuesong) <gengxues...@huawei.com<mailto:gengxues...@huawei.com>>; spring@ietf.org<mailto:spring@ietf.org>; Rishabh Parekh (riparekh) <ripar...@cisco.com<mailto:ripar...@cisco.com>>; Arvind Venkateswaran (arvvenka) <arvve...@cisco.com<mailto:arvve...@cisco.com>> Subject: 答复: Comments on draft-geng-spring-sr-redundancy-protection 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<mailto:gengxues...@huawei.com>>; spring@ietf.org<mailto:spring@ietf.org>; Rishabh Parekh (riparekh) <ripar...@cisco.com<mailto:ripar...@cisco.com>>; Arvind Venkateswaran (arvvenka) <arvve...@cisco.com<mailto: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. Zzh> Since the presentation talked about scenario where the (FI, SN) information is already carried, it is fair to discuss that in my initial comments; I understand that you want to focus on the other scenario, and that’s fine – see later comments below. Fan>> I read the draft of replication segment, and have two questions if replication segment is used in redundancy protection. 1) I believe merging node should be as the downstream node, since the nodes in precedence of merging node should not be redundancy protection aware. In this case, there will be at least two identical downstream nodes. In replication segment, there is no definition of such a situation. Zzh2> That is not explicitly excluded, and that does not mean it can’t be used. 2) The draft states replication SID MUST only appear as the ultimate SID in a SID list. What if the merging node is not the last node of the SRv6 E2E path? Zzh2> There is a requirement that there must be no “topological” SID. The intention is to prevent the situation where a node side comes after the replication SID, causing duplicate packets to that node. That is reasonable for the original intention of replication segment, but now it is reasonable to remove that because of this new use case of replication segment where we do want the replicated packets to the same merging node. We’d rather remove the restriction instead of defining a new segment. 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. Zzh> IPv6 flow label is irrelevant here – it’s not discussed in either your draft/presentation or in my comments – so we can ignore this. Fan>> I mentioned IPv6 flow label coz we had this discussion in DetNet WG. I agree we can come back to this thread when it is needed. https://mailarchive.ietf.org/arch/browse/detnet/?q=flow%20identification%20in%20ipv6<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/browse/detnet/?q=flow*20identification*20in*20ipv6__;JSUl!!NEt6yMaO-gk!Xgth91A6kCK6jXojQgQDaqWbfJ99HWzdkEjEJg3Wt5JxGsQ9uLf_E9w2W1ImkT4T$> 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. Zzh> RFC 8986 does specify additional flavors of End and End.X function with USP, PSP and USD behaviors which are modifications to base End and End.X function; exactly what we are proposing here – enhancing Replication Segment to add (FI,SN) when required. Fan>> can you explain more? I don’t see correlation between flavors and adding (FI,SN). 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. Zzh> Adding (FI, SN) information is only to replication segments that are used for replication for unicast redundancy purpose. It does not mean all replication segments will be added with (FI, SN) semantics. Fan>> How would you write the Boolean switch to differentiate the purpose of multicast replication and redundancy protection in one segment? And currently we don’t exclude the redundancy protection for multicast traffic. Zzh2> There are two ways to do it. Zzh2> 1. A replication segment now carries an additional attribute about adding FI/SN information. That does mean the redundancy node cannot use the same replication segment for both regular replication (w/o adding FI/SN information) and redundancy replication purposes. However, that does not mean we should not extend the existing replication segment for redundancy purpose. Also note an interesting use of replication segments here – say the redundancy node is N1 (who adds the FI/SN information) but the actual replication node could be N2. The replication tree does start at N1 but only one copy is sent to N2, who does the real replication. Now N1 will have two replication segments – one for regular multicast purpose and one for redundancy, but they will share the same replication segments downstream (because only the redundancy node adds the FI/SN information). Zzh2> 2. We can separate out the semantics of adding FI/SN. This is easy to do with SRv6 – just use the argument bits to indicate that. For MPLS, a separate label may be used before the regular replication SID – that label will add the FI/SN information and the following replication SID will do the replication. Zzh2> Not excluding redundancy protection for multicast traffic is actually a good reason to use replication segment 😊 You can see that a replication segment, either with “adding FI/SN” semantics embedded or explicitly indicated by a preceding “add FI/SN” label or by a trailing “add FI/SN” SRv6 arg bits, can be used for both multicast and unicast traffic. In case of multicast, as long as two or more branches eventually converge to the merge node, redundancy protection is achieved. Zzh> I don’t follow your argument about “seems a waste and unpractical to URLLC service”. Zzh> I don’t follow your argument about “Twisting them together in one segment results in a complicated function where maybe only one type of service is required on the node” either. If you only need regular multicast service, the replication segment does not need the semantics to add (FI, SN) information. If you need redundancy protection then the replication segment does have the semantics to add (FI, SN) information). If you need both, then some will have that semantics and some will not; and if you have a scenario where you don’t need to add (FI, SN) information for redundancy protection then the existing replication segment w/o the additional semantics to add (FI, SN) information can be used for both. All can be achieved with a simple Boolean switch added to the replication segment. Fan>> after seeing all these “if, then” shown above, I even feel more strongly to support separating two segments. ☺ In RFC8986, there is no single Endpoint behavior having such “if, then” structure to specify different functions. Zzh> Note that Replication Segment is not tied to multicast either (the draft only mentioned multicast once as one use case): We define a new type of segment for Segment Routing [RFC8402<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8402__;!!NEt6yMaO-gk!Xgth91A6kCK6jXojQgQDaqWbfJ99HWzdkEjEJg3Wt5JxGsQ9uLf_E9w2WwrIuotL$>], called Replication segment, which allows a node (henceforth called as Replication Node) to replicate packets to a set of other nodes (called Downstream Nodes) in a Segment Routing Domain. Replication segments provide building blocks for Point-to-Multipoint Service delivery … Zzh> It is about replicating packets to a set of other nodes – quite applicable here as a building block. Fan>> I do think replication segment has a very elegant design, however identical downstream nodes, design of P2MP SR policy (indirectly involves Tree-ID) may seem burden too much on redundancy segment. But it is still very welcome to have further discussion on replication segment and redundancy segment. Zzh2> Please see comments earlier 😊 Zzh2> Also tree-id is not a concern. Tree-ID is only needed when multiple replication segments need to be signaled to different tree nodes. A simple redundancy case is like ingress replication and only a single replication segment is needed so tree-id is just an internal thing on the redundancy node. Regardless, the key is that the existing redundancy segment concept can be used for redundancy purpose. 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. Zzh> While I do think it is better to put the actual (FI, SN) information in the DOH, I did not talk about adding (FI, SN) information to the arg part of an SRv6 SID. I was saying that the argument of an SRv6 replication SID can serve as that Boolean switch to indicate if (FI, SN) information needs to be added. Fan>> so far, this approach works for me. Zzh2> It can work, but since only the merging node use the FI/SN information, it is more of a DOH thing instead of SRH thing. Zzh2> Thanks! Zzh2> Jeffrey 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. Zzh> I forgot that DETnet mpls data plane already reuses PW CW for SN information. That’s fine and no need to introduce GDFH for MPLS. Zzh> Thanks. Fan>> thanks for bring up this topic to a deeper discussion. Redundancy protection should be taken into consideration for both SP and vendor if URLLC services should be guaranteed. Zzh> Jeffrey Thanks. Jeffrey Juniper Business Use Only _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Rk0PGf0pg0nFb0yo3yrw4HCuRzBBn_xDVWjwUQ9HKkn1db_vI48SfuShKITTo6uG$> Juniper Business Use Only _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Xgth91A6kCK6jXojQgQDaqWbfJ99HWzdkEjEJg3Wt5JxGsQ9uLf_E9w2W16NLBQX$> Juniper Business Use Only
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
