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

["Yangfan (IP Standard)" <[e-mail]>]

Hi Jeff,

One single comment starts with Fan1>>.

Regards,
Fan

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

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


Juniper Business Use Only