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

From: "Yangfan (IP Standard)" <[email-masked]>
Date: Fri, 4 Jun 2021 16:10:40 +0000

Hi Jeff,
I am coming back. Please see inline comments starts with Fan1>>.

发件人: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
发送时间: 2021年5月27日 4:26
收件人: Yangfan (IP Standard) <[email-masked]>; 'Rishabh Parekh' <[email-masked]>
抄送: 'Arvind Venkateswaran (arvvenka)' <[email-masked]>; Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]' <[email-masked]>; 'Rishabh Parekh (riparekh)' <[email-masked]>
主题: RE: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

Hi Fan,

In this thread I’ll address another point that I deferred. I snipped unrelated text.

Zzh6> It’s important to distinguish between control plane and data plane. In data plane it is always a simple SID (replication or redundancy). In control plane (that sets up the replication/redundancy state on relevant nodes), it could be whatever.

Fan> I try to compare the two solutions redundancy protection and P2MP replication as follows, hope it can help the understandings.

Format: <solution> ,  <identifier of service> ,  <how it works>
<redundancy protection> , <Redundancy SID> ,  <service is identified by Red-SID, Red-SID triggers redundancy policy to assign candidate paths between redundancy node and merging node>
<P2MP replication> ,  <P2MP policy identifier (root-id, tree-id)> ,  <P2MP policy gives the tree structure of the P2MP service, replication segment is an atomic building block for packet replication and stays in root, bud and leaf>

Although each solution includes a SID and a SR-Policy, there are totally different mechanisms. I don’t think it is just a representation difference.

In your representation for Redundancy solution, you mentioned “candidate paths”. I would change it to “replication branches”, because “candidate paths” in SR policies have a different meaning.
Fan1>> Firstly, I don’t see much difference of candidate path either in SR policy or in Redundancy policy.

Basically, the redundancy policy would replicate incoming traffic and send them down to different paths.
Fan1>> Secondly, redundancy policy doesn’t specify the replication instruction, which is indicated by redundancy segment. Redundancy policy just extends SR policy to support more than one usable candidate path. Though it is not detailed explained in the draft, you can simply regard redundancy policy as an SR policy including two candidate paths with same preferences.

No additional replication is done downstream and this corresponds to the “Ingress Replication” concept in multicast/p2mp.
Fan1>> in our design, the headend and endpoint of redundancy protection would be the redundancy node and merging node. In terms of your solution, downstream node would be the merging node. Of course you can put elimination behavior in the other nodes behind the node at which the packets from different path actually flow to and get together, but this is how you put the redundancy protection mechanism in your solution.

For <identifier of service>, you used “redundancy SID” and “P2MP policy identifier” respectively. As I mentioned before, in the data plane both just use a SID. In the control plane (i.e., how the replication/redundancy segment is installed), the identifier could be anything for both solutions, including a SID.

For replication segment based solution, unless the replication is to more than two copies and done by a multi-level tree (node 1 replicating to node 2 and 3, and then node 2 replicating to node 4 and 5), then it is “Ingress Replication” and no different from the redundancy segment solution.

BTW, P2MP policy (with tree identification, candidate paths, set of leaves, etc.) are really just control plane information on the root. It does not give the tree structure either. Instead, the entire replication tree are just concatenated replication segments on root, leaves and intermediate replication nodes. The intermediate replication nodes are optional (i.e., Ingress Replication), and in that case there is no difference from the redundancy segment.

Fan1>> From data plane perspective, replication segment and redundancy segment share the replication instruction, differ from whether to encap FI and SN at the same time. I will leave this FI,SN adding discussion to another email thread.
However, from control plane perspective, two solutions are quite different on how redundancy protection service is provided. Since redundancy protection is more likely used in unicast scenario, (it can be used for multicast, but let’s leave it to a separate thread), it doesn’t make sense to extend BGP MVPN attribute for a unicast redundancy protection service.

Again, I don’t argue the possibility of using replication segment and P2MP policy as one solution to provide redundancy protection. We provide our approach to achieve redundancy protection. Replication segment is just the second approach. But I don’t believe the saying that the approach A is the approach B. Actually, both of them can the solutions to provide redundancy protection. I even think we can collaborate on this topic. What do you think? ☺

Regards,
Fan

Jeffrey

Juniper Business Use Only

---

From: "Yangfan (IP Standard)" <[email-masked]>
Date: Fri, 4 Jun 2021 17:01:20 +0000

Hi Jeff,

One single comment starts with Fan1>>.

Regards,
Fan

发送时间: 2021年5月27日 3:37

Hi Fan,

In this email I will focus on two points that I deferred earlier. I snipped unrelated text.

…
Fan 4>>: I re-thought the adding of FI/SN last week. Adding FI at the SR ingress node may also bring benefits. Ingress node usually identifies the service, for example L3VPN service, or L3VPN service with a specific DSCP value. Thus, for some services, it would be easier for ingress node to identify a flow needing redundancy protection. I don’t deny this possibility.  However, I believe FI can be added equally either at ingress node or at redundancy node.
With regards to SN, redundancy node is still the best choice. There is another thread in DetNet discussing about the sequence number state. https://mailarchive.ietf.org/arch/msg/detnet/zDBweFj3g4L2KtukueMBD_tclpM/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/detnet/zDBweFj3g4L2KtukueMBD_tclpM/__;!!NEt6yMaO-gk!SFu4iFEUSQn3gHkdUctEVeB8tdd5-Dxs7Sqok8oOp8q5taMhsLcfGOx87mub1BZP$>
People believe there is sequence number state maintenance in replication function, elimination function and reordering function. In this case, SN had better to be added at redundancy node.

…
Zzh6> I will not try to get away with keep deferring things. So far there are three things that I have deferred: 1. Why I think it’s better to do the SN at the ingress 2. The email thread you referred to above 3. This one. I will come back to them 😊

I don’t see how the email thread you referred to leads to that the redundancy node should add the SN.
Moreover, in the relevant draft-varga-detnet-pof there is the following figure(the red numbers after the R/E nodes are added by me to indicate different PRF/PEF nodes):

                                          +------------+
                +---------------E1---+    |            |
   +----+       |               |    +----R3--+        |          +----+
   |src |-------R1          +---+             |        E3----O----+ dst|
   +----+       |           |                 E2-------+          +----+
                +-----------R2                |
                            +-----------------+

   R: replication point (PRF)
   E: elimination point (PEF)
   O: ordering function (POF)

Notice that POF node is after the last PEF, which means the flow itself must have its SN.
Also Notice that E1 is after staggered R1/R2 and E2 is after staggered R2/R3, which means E1/E2 must rely on the SN in the original flow, not on the SN added by R1/R2/R3.

Fan1>> I agree with you, in DetNet FI and SN are added and removed at the edge nodes. In terms of DetNet in MPLS, FI is identified by DetNet service label, and RFC8964 specifies DetNet S-label in many aspects.
Redundancy protection in SRv6 may go beyond the specification of S-Label in MPLS DetNet. Actually I was thinking we’d better include all possibilities in the draft, adding FI,SN either at the headend or redundancy node, just put an extra check point at redundancy node.

Fan

Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 7 Jun 2021 14:47:12 +0000

Hi Fan,

Please see zzh1> below.

From: Yangfan (IP Standard) <[email-masked]>
Sent: Friday, June 4, 2021 12:11 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; 'Rishabh Parekh' <[email-masked]>
Cc: 'Arvind Venkateswaran (arvvenka)' <[email-masked]>; Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]' <[email-masked]>; 'Rishabh Parekh (riparekh)' <[email-masked]>
Subject: 答复: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

[External Email. Be cautious of content]

Hi Jeff,

发件人: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
发送时间: 2021年5月27日 4:26
收件人: Yangfan (IP Standard) <[email-masked]<mailto:[email-masked]>>; 'Rishabh Parekh' <[email-masked]<mailto:[email-masked]>>
抄送: 'Arvind Venkateswaran (arvvenka)' <[email-masked]<mailto:[email-masked]>>; Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>; 'Rishabh Parekh (riparekh)' <[email-masked]<mailto:[email-masked]>>
主题: RE: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

Hi Fan,

Zzh1> What does your “candidate path” mean exactly? Why do they have the same preference? With the CP concept in SR policies, only one of the CPs will be chosen and only one copy of the traffic will be sent out.

No additional replication is done downstream and this corresponds to the “Ingress Replication” concept in multicast/p2mp.
Fan1>> in our design, the headend and endpoint of redundancy protection would be the redundancy node and merging node. In terms of your solution, downstream node would be the merging node. Of course you can put elimination behavior in the other nodes behind the node at which the packets from different path actually flow to and get together, but this is how you put the redundancy protection mechanism in your solution.
Zzh1> With the replication segment method, the elimination behavior does *not* have to another node behind the node where replicated packets will get together.

Fan1>> From data plane perspective, replication segment and redundancy segment share the replication instruction, differ from whether to encap FI and SN at the same time. I will leave this FI,SN adding discussion to another email thread.
Zzh1> whether to add FI/SN is just an additional item that can be added to the replication segment (when it is used for redundancy purpose).
However, from control plane perspective, two solutions are quite different on how redundancy protection service is provided. Since redundancy protection is more likely used in unicast scenario, (it can be used for multicast, but let’s leave it to a separate thread), it doesn’t make sense to extend BGP MVPN attribute for a unicast redundancy protection service.
Zzh1> There are two aspects when it comes to control plane.
Zzh1> a) setup of the redundancy/replication segment on the redundancy node. To me this is the same for both (the replication segment setup can be augmented with an “add FI/SN” semantics if necessary).
Zzh1> b) signal to the ingress node of the binding SID for redundancy purpose. To me this is also the same for both.
Again, I don’t argue the possibility of using replication segment and P2MP policy as one solution to provide redundancy protection. We provide our approach to achieve redundancy protection. Replication segment is just the second approach. But I don’t believe the saying that the approach A is the approach B. Actually, both of them can the solutions to provide redundancy protection. I even think we can collaborate on this topic. What do you think? ☺
Zzh1> I just don’t see there is a need to have a separate redundancy policy/segment because they’re almost identical - the replication policy/segment can provide what you need. This does not mean that we don’t need this draft-geng anymore. If I have convinced you, you only need to refer to the replication policy/segment drafts in draft-geng and we only need to augment the replication policy/segment with the function of adding FI/SN if we agree that is needed for some scenarios.
Zzh1> Thanks.
Zzh1> Jeffrey

Regards,
Fan

Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 7 Jun 2021 14:51:46 +0000

Hi Fan,

When possible, we should try to implement for mpls and SRv6 data plane similarly.
In fact, not adding FI/SN at the replication node is more important for SRv6 – it’d save you an extra IPv6 header.

Jeffrey

Sent: Friday, June 4, 2021 1:01 PM

Hi Jeff,

Regards,
Fan

Hi Fan,

…

…

                                          +------------+

Fan

Jeffrey

---

From: "Yangfan (IP Standard)" <[email-masked]>
Date: Thu, 10 Jun 2021 12:20:25 +0000

Hi Jeff,
Please see the inline comments below starts with Fan2>>.

发送时间: 2021年6月7日 22:47

Hi Fan,

Please see zzh1> below.

From: Yangfan (IP Standard) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, June 4, 2021 12:11 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; 'Rishabh Parekh' <[email-masked]<mailto:[email-masked]>>
Cc: 'Arvind Venkateswaran (arvvenka)' <[email-masked]<mailto:[email-masked]>>; Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>; 'Rishabh Parekh (riparekh)' <[email-masked]<mailto:[email-masked]>>
Subject: 答复: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

Hi Jeff,

Hi Fan,

Zzh1> What does your “candidate path” mean exactly? Why do they have the same preference? With the CP concept in SR policies, only one of the CPs will be chosen and only one copy of the traffic will be sent out.
Fan2>> Yes, the above is correct according to current specification of SR policy. The target of redundancy policy is to give more than one paths to redundancy node to be encapsulated on the replicas. It can be indicated by different candidate paths, or even different segment lists in one candidate path. We can work on the details until the discussion of redundancy segment becomes clear.

-----snip it from email in May 20--------
Zzh> The ingress will send packets with SL <A, R, M>. SID A gets the packet to A, who sees R and do the replication (R is not popped by A). D sees R in the SL and pops R (this is the replication segment behavior on a leaf). It then sees M and do the merging. Alternatively, A could pop R so D will see M directly and do the merging.
Fan2>> popping  R to process M may work in SR-MPLS, not SRv6.
if the merging node is the downstream node, section 2.2 SRv6 data plane of draft-~-replication-segment says,
“For a leaf node, the packet is decapsulated and the inner packet is forwarded as per local configuration. ”
It’s saying IPv6 +SRH header is removed when R SID is processed on downstream node (equals to merging node). Even though M SID is encapsulated in SID list, there is no opportunity to process it. Do I understand it correctly?

Fan2>> I’d like  to go deep to understand how replication segment can be used in both SR-MPLS and SRv6 data planes first. This process will also bring benefit on how to arrange the drafts finally.
Thanks.
Fan

Zzh1> Thanks.
Zzh1> Jeffrey

Regards,
Fan

Jeffrey