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

["Joel M. Halpern" <[e-mail]>]

Fan, I am a bit confused by your statement below.
the Detnet architecture, and the sublayer split therein, is not specific 
to SR-MPLS.  It applies as much to SRv6.  It would be very unusual, and 
need strong justification, for the SPRING WG to decide to change the 
published Detnet architecture.

Yours,
Joel (speaking as a participant)

On 6/4/2021 5:44 AM, Yangfan (IP Standard) wrote:
> Hi Jeffrey,
> 
> You are right about how redundancy protection is used in SR-MPLS. In 
> DetNet definition, S-label is purely functional not routable as it is in 
> service sub-layer. In the draft, we separate the redundancy segment 
> specification in two subsections, SR-MPLS and SRv6. For SR-MPLS, 
> redundancy segment obeys RFC8964. We are aligned on this point.
> 
> Regarding SRv6, DetNet doesn’t have SRv6 data plane specification, so 
> redundancy protection has no guide to follow. In the latest version of 
> draft, redundancy protection is defined to extend the capabilities in SR 
> paradigm to support the redundancy protection in a DetNet environment. 
> It should be allowed to define redundancy segment as a routable segment 
> in SRv6.
> 
> I will set aside time to reply to your other emails today. Thanks a lot! J
> 
> Fan
> 
> *发件人:*Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
> *发送时间:*2021年5月27日1:42
> *收件人:*Yangfan (IP Standard) <[e-mail]>; 'Rishabh 
> Parekh' <[e-mail]>
> *抄送:*Gengxuesong (Geng Xuesong) <[e-mail]>; 'Rishabh 
> Parekh (riparekh)' <[e-mail]>; 'Arvind Venkateswaran 
> (arvvenka)' <[e-mail]>; '[e-mail]' <[e-mail]>
> *主题:*RE: [spring] RE: Comments on 
> draft-geng-spring-sr-redundancy-protection
> 
> Hi Fan,
> 
> More discussions on whether the redundancy/merging segment is a 
> topological/routable segment.
> 
> In case of SR-MPLS, draft-geng says:
> 
>     In SR over MPLS, Redundancy Segment acts as DetNet S-Label to
> 
>     explicitly identify the replication function on redundancy node.
> 
>     Redundancy segment is allocated from redundancy node, and is
> 
>     provisioned to the ingress node of SR domain by the controller plane
> 
>     via PCEP, BGP, or NetConf protocols.
> 
> According to RFC 8964:
> 
>     S-Label       A DetNet "service" label that is used between DetNet
> 
>                   nodes that implement the DetNet service sub-layer
> 
>                   functions.  An S-Label is used to identify a DetNet
> 
>                   flow at the DetNet service sub-layer at a receiving
> 
>                   DetNet node.
> 
> The S-label identifies the flow only. PRF/PEF/POF are not indicated by 
> the S-label, though the <S-label, SN> provides information needed for 
> PEF/POF.
> 
> Additionally, an S-Label certainly is not routable. If you consider the 
> redundancy node A and merging node D a pair of DetNet source/destination 
> node, adding PEF/POF semantics to an S-label may be reasonable (A 
> imposes the S-label and D knows that the S-label has merging semantics). 
> However, for the label that the ingress node imposes, which has both the 
> “route to A” and “Replicate by A” semantics, calling it an S-Label just 
> does not conform to RFC 8964.
> 
> In SRv6 case, while you could say that the redundancy segment is a 
> routable one, but that is true for an replication segment as well. An 
> SRv6 SID is a <locator, function, argument> tuple. A replication SID is 
> really just the “function” part, and the locator is used to get to the 
> node – whether it is a root, leaf or intermediate replication node.
> 
> Jeffrey
> 
> *From:*Yangfan (IP Standard) <[e-mail] 
> <mailto:[e-mail]>>
> *Sent:* Thursday, May 20, 2021 8:59 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail] 
> <mailto:[e-mail]>>; 'Rishabh Parekh' <[e-mail] 
> <mailto:[e-mail]>>
> *Cc:* Gengxuesong (Geng Xuesong) <[e-mail] 
> <mailto:[e-mail]>>; 'Rishabh Parekh (riparekh)' 
> <[e-mail] <mailto:[e-mail]>>; 'Arvind Venkateswaran 
> (arvvenka)' <[e-mail] <mailto:[e-mail]>>; 
> '[e-mail]' <[e-mail] <mailto:[e-mail]>>
> *Subject:* 答复: [spring] RE: Comments on 
> draft-geng-spring-sr-redundancy-protection
> 
> *[External Email. Be cautious of content]*
> 
> Hi Jeff,
> 
> Thank you for your explanations about the SID list encapsulation and SID 
> process on each node. It did help a lot to understand how Replication 
> SID can be used in redundancy protection.
> 
> I move one of your comments from the other email here to focus on the 
> packet forwarding discussion in this thread.
> 
> As for the 3 deferred “homework”, feel free to come back when you are 
> available.
> 
> Much appreciated with these deep discussions. Some feedbacks please see 
> inline.
> 
> Regards,
> 
> Fan
> 
> *发件人:*Jeffrey (Zhaohui) Zhang [mailto:[e-mail] 
> <mailto:[e-mail]>]
> *发送时间:*2021年5月20日1:43
> *收件人:*Yangfan (IP Standard) <[e-mail] 
> <mailto:[e-mail]>>; 'Rishabh Parekh' 
> <[e-mail] <mailto:[e-mail]>>
> *抄送:*Gengxuesong (Geng Xuesong) <[e-mail] 
> <mailto:[e-mail]>>; 'Rishabh Parekh (riparekh)' 
> <[e-mail] <mailto:[e-mail]>>; 'Arvind Venkateswaran 
> (arvvenka)' <[e-mail] <mailto:[e-mail]>>; 
> '[e-mail]' <[e-mail] <mailto:[e-mail]>>
> *主题:*RE: [spring] RE: Comments on 
> draft-geng-spring-sr-redundancy-protection
> 
> Hi Fan,
> 
> Sorry for the late response. Please see zzh> below.
> 
> *From:*Yangfan (IP Standard) <[e-mail] 
> <mailto:[e-mail]>>
> *Sent:* Monday, May 17, 2021 9:20 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail] 
> <mailto:[e-mail]>>; 'Rishabh Parekh' <[e-mail] 
> <mailto:[e-mail]>>
> *Cc:* Gengxuesong (Geng Xuesong) <[e-mail] 
> <mailto:[e-mail]>>; 'Rishabh Parekh (riparekh)' 
> <[e-mail] <mailto:[e-mail]>>; 'Arvind Venkateswaran 
> (arvvenka)' <[e-mail] <mailto:[e-mail]>>; 
> '[e-mail]' <[e-mail] <mailto:[e-mail]>>
> *Subject:* RE: [spring] RE: Comments on 
> draft-geng-spring-sr-redundancy-protection
> 
> *[External Email. Be cautious of content]*
> 
> Hi Jeffrey,
> 
> To summarize the discussions a bit, I have two questions and hope to 
> hear your comments and clarifications.
> 
> Q1: Are there any questionsfor clarifications or open issueswith the 
> current solution of redundancy-SID+Merging-SID+redundancy policy? If so, 
> we would like to clarify them first.
> 
> Zzh> No.
> 
> Fan1>> It is very good and important if the current redundancy 
> protection mechanism can be understood clearly in WG.
> 
> Q2:
> 
> Figure 1 in draft-geng-spring-sr-redundnacy-protection is the typical 
> topology for Redundancy Protection in SR domain, as shown below.
> 
> ingress------A (R)-------B-------D(M)-------egress
> 
>          +------C------------+
> 
>                      +----E-------+
> 
> Could you please explain how exactly Tree-SID solution is used in data 
> plane for redundancy protection? For example, how the SR SID List is 
> assigned, how the packet is encapsulated and forwarded from R1 to R2 in 
> data plane, how Tree-SID and Replication SID are configured on network 
> nodes, etc.
> 
> Zzh> I sort of replied in my late response to the other email, but let 
> me reply here as well because that thread was indeed getting very deep.
> 
> Zzh> I changed the letters so that we can distinguish between node 
> representation and function representation. A is the redundancy node and 
> D is merging node. I also added another node E.
> 
> Zzh6> Unlike unicast where you use a segment list to encode the path 
> that a packet flows through, with multicast it is impractical to encode 
> a (sub-)tree as a segment list. Therefore, for SR-P2MP, an replication 
> tree is not represented by a segment list. Rather, each 
> root/replication/leaf node on a tree installs a replication segment to 
> represent how replication is done on that node for that tree, and only 
> one SID is needed in the packet for it to flow from the root to all the 
> leaves through the intermediate replication points. This is exactly like 
> today’s P2MP tunnel in the forwarding plane. We can put aside the 
> argument “oh this requires per-flow state” here, as it is not relevant 
> to our topic here.
> 
> Fan1>> To differentiate the node representation and function 
> representation actually reveals a significant difference between 
> Replication SID and Redundancy SID.  In terms of SRv6, Replication 
> Segment is a local and non-routed segment, and Redundancy Segment is a 
> routed segment. And the merging segment in redundancy protection is also 
> a routed (topological) SID with merging function.
> 
> As you mentioned, it is impractical to use a segment list to encode a 
> tree for multicast traffic. So Replication SID only represents the 
> replication function, moreover is designed to separate with the routed 
> Node SID, however the benefit is Replication SID can be identical on one 
> tree.
> 
> Meanwhile, Redundancy Segment is usually used for unicast traffic, it is 
> straightforward to design it as a routed and functional segment. It is 
> not necessary to separate the route and function apart into different 
> SIDs, at least it saves one 128bit SID space.
> 
> Zzh> Let’s say that we’ll only make two copies for D to receive. A and D 
> have replication segment R installed. R on A simply says “make two 
> copies, one through B and one through C”. B/C do not need any state 
> because A is simply going to tunnel through B/C respectively. R on D 
> simply says “I am a leaf so I just pop R”.
> 
> 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.
> 
> Zzh> Now let’s say we want to make three copies. The ingress will still 
> send the same SL. R on A now says “tunnel one copy to D through B and 
> send one copy to C” and C now also has R installed, saying “send one 
> copy to D directly and another copy to D via E”. Now three copies will 
> arrive on D (with A/C each replicating once). D sees R SID and pops the 
> R SID (as the behavior of replication segment on leaf). It then sees M 
> and do the merging.
> 
> Zzh> The replication is pure SR-P2MP behavior (assuming A does not need 
> to add FI/SN). M is pure non-topological merging behavior (relying on 
> the FI/SN added by the ingress node).
> 
> Fan1>> Thanks for your detailed explanations in this and other email, 
> now I think I understand how data plane works.  There are still details 
> needs further discussion,  e.g. in terms of SRv6, if B/C is downstream 
> nodes, in this sentence “D sees R SID and pops the R SID” pop means 
> remove the IPv6 header, in this case M SID will not be processed. But 
> that’s all right, there are surely a lot details if you want to design 
> one unified Segment can work for P2MP multicast and redundancy 
> protection, also unified in SR-MPLS and SRv6. We can surely continue the 
> discussions.
> 
> Zzh> Thanks.
> 
> Zzh> Jeffrey
> 
> I don’t think I understand the entire forwarding flow correctly. In fact 
> we are very interested in Tree-SID solution as it has been adopted as a 
> WG work. It would be very helpful if you or anyone can provide a 
> detailed illustration or comparison, for instance like the way of the 
> Appendix in replication SID/Tree SID drafts.
> 
> Looking forward to your reply!
> 
> Best,
> 
> Fan
> 
> Juniper Business Use Only
> 
> Juniper Business Use Only
> 
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>