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

[Balázs Varga A <[e-mail]>]

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