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