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

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

Hi Joel,

Apology for not replying you in time. I misses out this email and was reminded by another author yesterday.  
Since the idea of redundancy protection comes from service protection specified in DetNet, we surely would like to keep redundancy protection accordance with specifications in DetNet architecture. In addition, as 5G evolves, we also see multiple services outside DetNet also require this ultra high reliability guarantee techonology. Therefore, redundancy protection in SR would become a common mechanism that works in both DetNet and non-DetNet environment. 
As Janos said in previous email, there is no specification of DetNet in SRv6 data plane. I think the problem here is that, in DetNet Segment Routing (both in MPLS and IPv6) is not regarded as a new data plane but a technology used in forwarding sub-layer. With SRv6 network programming, it somehow blurs the boundary between DetNet service sub-layer and forwarding sub-layer. I will leave the detailed discussion in Balazs' following up email yesterday. 
Again, we don’t initially intend to define a new protocol in SPRING to break DetNet architecture. These two WG are not two battlegrounds where we intentionally want to choose. There was a history and negotiation between two WGs. I think I made it clear when I presented this draft to SPRING and DetNet in IETF 107. I really don’t want to see there is misunderstanding on the motivation.
The authors believe Segment Routing brings new capabilities to IP and MPLS data planes, and would like to make use of these great capabilities to provide DetNet services. That is what we are trying to do in this draft. Of course, during the draft progress, we are happy to discuss whether it violates DetNet architecture or not. 
Forgive me if I misspoke any incorrect words as a non-native speaker. I will try to make it clear and correct in future.
Thanks a lot, and have a nice weekend!

Best regards, 
Fan

-----邮件原件-----
发件人: detnet [mailto:[e-mail]] 代表 Joel M. Halpern
发送时间: 2021年6月4日 20:57
收件人: Yangfan (IP Standard) <[e-mail]>; Jeffrey (Zhaohui) Zhang <[e-mail]>; 'Rishabh Parekh' <[e-mail]>
抄送: '[e-mail]' <[e-mail]>; DetNet WG <[e-mail]>
主题: Re: [Detnet] [spring] 答复: RE: Comments on draft-geng-spring-sr-redundancy-protection

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 
> Zzh> 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 
> Zzh> 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 
> Zzh> 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
> 

_______________________________________________
detnet mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/detnet