Re: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

[Rishabh Parekh <[e-mail]>]

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) <
[e-mail]> wrote:

> Hi Jeffrey,
>
> Apology for being so late to reply. Please see inline starts with Fan>>.
>
>
>
> Cheers,
>
> Fan
>
>
>
> *发件人:* spring [mailto:[e-mail]] *代表 *Jeffrey (Zhaohui)
> Zhang
> *发送时间:* 2021年3月30日 5:06
> *收件人:* Yangfan (IP Standard) <[e-mail]>; Gengxuesong
> (Geng Xuesong) <[e-mail]>; 'Rishabh Parekh (riparekh)' <
> [e-mail]>; 'Arvind Venkateswaran (arvvenka)' <[e-mail]>;
> [e-mail]
> *主题:* Re: [spring] Comments on draft-geng-spring-sr-redundancy-protection
>
>
>
> Hi Fan,
>
>
>
> Please see zzh> below.
>
>
>
> *From:* Yangfan (IP Standard) <[e-mail]>
> *Sent:* Friday, March 26, 2021 11:58 PM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>;
> Gengxuesong (Geng Xuesong) <[e-mail]>; [e-mail];
> Rishabh Parekh (riparekh) <[e-mail]>; Arvind Venkateswaran
> (arvvenka) <[e-mail]>
> *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:[e-mail] <[e-mail]>] 代表
> Jeffrey (Zhaohui) Zhang
> 发送时间: 2021年3月26日 3:19
> 收件人: Gengxuesong (Geng Xuesong) <[e-mail]>; [e-mail];
> Rishabh Parekh (riparekh) <[e-mail]>; Arvind Venkateswaran
> (arvvenka) <[e-mail]>
> 主题: [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
>
> [e-mail]
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>