Hi Shaofu, Yes, your summary 1-4 and 6 is correctly describing a possible DetNet use-case.
Further clarification on item 5: > … That is, the Redundancy Policy should be uniformly applied to all flows > that share this policy … Not necessarily “uniformly applied”. This is implementation and network design dependent, therefore not defined in detail. The Redundancy Policy contains _flow_ specific configuration of replication/elimination function(s). It defines the redundancy policy per Flow-ID. (Note, that Flow-ID is part of the ARG.) So, for example for Flow-ID1 it defines a replication function with 2 resulted member flows, for Flow-ID2 it defines an elimination function and for Flow-ID3 it defines a replication function with 3 resulted member flows. All these flows (ID1, ID2, ID3) needs its redundancy functionality on the given node, therefore they can use the same RSID. The flow specific redundancy functionalities are defined by the Redundancy Policy of the RSID. Thanks & Cheers Bala’zs From: [email protected] <[email protected]> Sent: Friday, April 17, 2026 9:58 AM To: Balázs Varga A <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [Detnet] Comments on draft-ietf-spring-sr-redundancy-protection Hi Bala'zs Thanks for your clarifications. It is clearer now to understand the solution. Basically, this document strictly follows the hierarchical sub-layers (forwarding & service) defined in DetNet. Based on your response, I summarized my understandings as follows with further one comment (see item 5): 1) A Redundancy Node has the capability to execute Redundancy Functionality, which further contains two entities: Encap/Decap Entityrelated with DetNet Forwarding Sub-layer, and Redundancy Protection Entity related with DetNet Service Sub-layer. 2) From the view of DetNet Service Sub-layer, there is an interconnection relationship of all Redundancy Nodes in the DetNet domain, and this will result in a DAG. Any Redundancy Node knows how many downstream Redundancy Nodes it has. This knowledge of interconnection seems to be provided by the Redundancy Policy installed at each Redundancy Node, not by flow states. The END.R SID is allocated per DAG (i.e., per Redundancy Policy, not per flow). Especially, the ingress PE is always a Redundancy Node. 3) Redundancy Policy defines the operations of Redundancy Functionality. The above two entities are actually defined in Redundancy Policy. 4) The configuration of Replication or Elimination for a Redundancy Node is independent of whether that node has downstream Redundancy Nodes. For example, Elm5. 5) The configuration of Replication or Elimination is defined by Redundancy Policy at each Redundancy Node, not by flow state of each given flow. That is, the Redundancy Policy should be uniformly applied to all flows that share this policy. Some text in the document like "as replication is configured for the given flow, ... ..." or "as elimination is configured for the given flow, ......" are misleading, can those text be revised ? 6) Both H.Encaps.R and END.R are only related to "Encap/Decap Entity related with DetNet Forwarding Sub-layer". The ingress PE apply Redundancy Policy for the arrvied user packet, and call H.Encaps.R to forward packet with metadata (FID/SN) to the downstream Redundancy Nodes. The transit Redundancy Node, after excecuting END.R behavior, apply the RSID-associated Redundancy Policy for the exposed user packet, and also call H.Encaps.R to forward packet .... Regards, PSF Original From: BalázsVargaA <[email protected]<mailto:[email protected]>> To: 彭少富10053815;[email protected] <[email protected]<mailto:[email protected]>>; Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; Date: 2026年04月16日 19:05 Subject: RE: [Detnet] Comments on draft-ietf-spring-sr-redundancy-protection Hi Shaofu, many thanks for the review and the supportive feedbacks. Clarifications & answers on your comments: 1, Redundancy Functionality Right, the packet replication/elimination happens in the Redundancy Functionality. However, the implementation details of the Redundancy Functionality are out-of-scope of the document. The draft describes only the node externally observable behaviors. Implementors are free to use e.g., an elimination algorithm (like VectorRecoveryAlgorithm described in 802.1CB). Replication is somewhat less complex to implement, but there are also various options. The draft separates two entities: (1) doing the encapsulation/decapsulation and (2) doing the redundancy protection. The H.Encaps.R encapsulation behavior defines only the (1) entity namely the packet encapsulation processing steps. Replication/elimination is done by the (2) entity. It is a similar concept to the MPLS data plane of DetNet (see RFC8964), where the DetNet-PW provides the tunnel between the DetNet Service Sub-layer Functions doing the replication/elimination. 2, End.R & Elimination As highlighted above End.R defines the (1) entity (i.e., it terminates the Redundancy Segment). End.R "handovers" the payload together with the meta data included in the RSID (Flow-ID, SeqNum) to the Redundancy Entity, that executes the redundancy protection (replication, elimination or their combinations). Configuration of the Redundancy Entity is defined by the Redundancy Policy of the RSID. 3, SR Policy Headend Behaviors Like in the previous comment, the draft separates two entities (1, encap/decap and 2, replication/elimination). Right, the text could be made clearer e.g., by adding a note in 4.2.1 section. CURRENT TEXT When a node "N" receives a packet P=(A, B) identified as a Flow for redundancy. B is neither a local address nor SID of "N". It executes the Flow related Redundancy function(s), resulting in one or more member flow (P1=(A, B), P2=(A, B), ...) with related parameters ([Flow-ID1, SeqNum], [Flow-ID2, SeqNum], ...). NEW TEXT When a node "N" receives a packet P=(A, B) identified as a Flow for redundancy. B is neither a local address nor SID of "N". It executes the Flow related Redundancy function(s), resulting in one or more member flow (P1=(A, B), P2=(A, B), ...) with related parameters ([Flow-ID1, SeqNum], [Flow-ID2, SeqNum], ...). Note: The number of resulting member flows depends on the configuration of the Flow related function(s). For example, in case of elimination there is only one member flow. END CURRENT TEXT After the H.Encaps.R behavior, P1, and P2 respectively look like: NEW TEXT After the H.Encaps.R behavior, P1, and P2 (if exists) respectively look like: END 4, Appendix, Elm5 No, Elm5 is doing only elimination. The packet processing is as follows: 1, execute END.R behavior, to expose the inner user packet and the related meta data (Flow-ID, SeqNum); 2, redundancy functionality finds that elimination is configured for this flow, so it performs elimination; 3, the user packet that still survive after elimination is encapsulated using H.Encaps.R and it is sent to the downstream redundancy node (Elm6). 5) An alternative design choice using existing P2MP SID (RFC9524) Yes and No. Whereas the P2MP SID acts similar to replication of redundancy protection, there are differences. The problem with the P2MP SID is that it does not contain the meta data (Flow-ID, SeqNum) needed for duplicate elimination. Again, many thanks for the questions/comments. Cheers Bala'zs From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Friday, April 10, 2026 10:32 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [Detnet] Comments on draft-ietf-spring-sr-redundancy-protection Hi Authors, Thanks for your work on this topic. I have some comments for this document. (as it is also related with DetNet, so CC) 1) Suggest clearly describing in the document what exactly the mentioned Redundancy Functionality includes, e.g., including replication function and elimination function ? If it includes replicaiton, then the text #quote# "Note, that the algorithm used by the Redundancy Functionality is not within the scope of this document." may be not correct, because the H.Encaps.R encapsulation behavior defined in the document is actually the algorithm of replicaiton. 2) In the Upper-Layer processing of END.R, there seems to contain elimination function. If that's the case, suggest to explicitly mention it in section "4.1. Redundancy Segment Endpoint Behavior" so that readers won't try to find descriptions related to elimination in section "4.2. SR Policy Headend Behaviors". #quote# " 4.1. Redundancy Segment Endpoint Behavior ... ... S04. Forward the exposed payload, type and the ARG part to the Redundancy functionality " 3) From examples in the appendix, section "4.2. SR Policy Headend Behaviors" should be the entry point for uniformly implementing Redundancy Functionality on user packet (whether the original user packet received by the ingress PE or inner user packet exposed on the transit redundancy node), based on the user flow state. However, this section seems to only describe replication function, without mentioning elimination. This comment is actually related to the previous comment, which should either mention elimination in the END. R behavior or in the H. Encaps. R processing. #quote# " 4.2.1. H.Encaps.R: SR Headend with Redundancy When a node "N" receives a packet P=(A, B) identified as a Flow for redundancy. ... ... " 4) Before the above comments are clarified, I have some doubts about the examples in the appendix. Please see the operation of Elm5. Firstly, it execute END. R behavior, to expose the inner user packet; Then, the user packet match the flow state, and find that elimination is configured for tihs flow, so perform elimination; Finally, the user packet that still survive after elimination is matched with the flow state again, and find that replication is configured, so perform H.Encaps.R and send to the downstream redundancy node Elm6. That is, at the Elm5 node, two functions (elimination & replicatioin) are configured for a flow at the same time, right? Overall, it is hoped that when describing the processing of packets (including pseudocode) in the document, where Redundancy Functionality appears, it can be more specific in distinguishing whether it is replication or elimination, or both. 5) An alternative design choice, it seems that the functionality described in this document can also be implemented using existing P2MP SID (RFC9524). In this case, the P2MP SID is only installed on the Replication Node, and not on the Elimination Node. In the SID list from the one replication node to its downstream replication node (or egress PE), if there are Elimination nodes or Ordering nodes, they are contained in the SID list in the form of Elimination Service Function SID or Ordering Service Function SID. That is, Elimination or Ordering is considered a new type of Service Function. Of course, this choice is not relevant to this document, just want to hear the working group's opinion on this. Regards, PSF
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
