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]
