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. J 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> wrote: > Hi Jeffrey, > > Apology for being so late to reply. Please see inline starts with Fan>>. > > > > Cheers, > > Fan > > > > *发件人:* spring [mailto:spring-boun...@ietf.org] *代表 *Jeffrey (Zhaohui) > Zhang > *发送时间:* 2021年3月30日 5:06 > *收件人:* Yangfan (IP Standard) <shirley.yang...@huawei.com>; Gengxuesong > (Geng Xuesong) <gengxues...@huawei.com>; 'Rishabh Parekh (riparekh)' < > ripar...@cisco.com>; 'Arvind Venkateswaran (arvvenka)' <arvve...@cisco.com>; > 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> > *Sent:* Friday, March 26, 2021 11:58 PM > *To:* Jeffrey (Zhaohui) Zhang <zzhang=40juniper....@dmarc.ietf.org>; > Gengxuesong (Geng Xuesong) <gengxues...@huawei.com>; spring@ietf.org; > Rishabh Parekh (riparekh) <ripar...@cisco.com>; Arvind Venkateswaran > (arvvenka) <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 <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. > > > > 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. > > 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? > > > > 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 > > > > 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. > > > > 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. J 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://tools.ietf.org/html/rfc8402>], 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. > > > > 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. > > > > 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 > > 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 > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
