[spring] Re: [Detnet] Comments on draft-ietf-spring-sr-redundancy-protection

[[e-mail]]

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 <[e-mail]>
To: 彭少富10053815;[e-mail] <[e-mail]>;
Cc: [e-mail] <[e-mail]>;
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: [e-mail] <[e-mail]> 
 Sent: Friday, April 10, 2026 10:32 AM
 To: [e-mail]
 Cc: [e-mail]
 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