[spring] Chair Review of draft-ietf-spring-sr-redundancy-protection-07 (WGLC)

[Alvaro Retana <[e-mail]>]

Dear authors:

I have many questions and concerns, and I believe significant work is
required. To be clear, I'm not opposed to this work progressing, but the
draft is not ready in its current form.

Please see detailed comments inline below. I want to highlight some
high-level issues:

1. Is Path Protection required? (line 105)

2. Operational/Deployment guidance is present in several parts of the draft.
   Consider a standalone Operational Considerations section
   (see draft-ietf-opsawg-rfc5706bis).

3. The relationship between this work and DetNet documents:
   draft-ietf-detnet-srv6-svc-protection (line 272), rfc8939 (line 466), and
   the DetNet architecture in general should be clarified.

4. The elimination functionality adds state to the network at an egress
node,
   which represents a departure from the SR Architecture (rfc8402). This
needs
   to be discussed further (line 274).

5. What should be the characteristics of the FIDs? What happens if there are
   collisions? (line 443)

6. Provide guidance about the size of the FID and SN (line 466).

7. Expand on the concept of a Redundancy Policy and how it relates to
rfc9256
   (line 480).

8. An Implementation Description section is needed (line 494).

9. Several threats have not been addressed in the Security Considerations
   section (line 503). Also, consider draft-spring-srv6-security.


Please take these comments with others that you may receive during the WGLC.

Thanks!

Alvaro.


[Line numbers from idnits.]

...
91 1.  Introduction

93   Redundancy Protection is a generalized protection mechanism to
94   achieve the high reliability for service provided in a Segment
95   Routing (SR) network.  Specifically, packets of flows are replicated
96   at a replication network node into two or more copies, which are
97   transported via different and disjoint paths in parallel.  On the
98   elimination network node, the multiple copies are received, redundant
99   packets eliminated, and only a single copy of the packet is
100   forwarded, the redundant copies are eliminated.  This mechanism is
101   commonly referred to as "Live-Live" as data traffic is forwarded on
102   the protection paths simultaneously.  One new SRv6 Segment Endpoint
103   Behavior is introduced to provide the replication and elimination
104   functions on specific network nodes by leveraging SRv6 Network
105   Programming capabilities.  In case of redundancy protection, there is
106   no need to perform switchover between protection paths as data
107   packets are sent simultaneously on multiple protection paths.
108   Redundancy protection can help to achieve zero packet loss target
109   when failure on either path happens.

[major] "In case of redundancy protection, there is no need to perform
switchover between protection paths as data packets are sent simultaneously
on multiple protection paths."

Does this text imply that there's no need for path protection of the
redundant flows?

The document doesn't dive into how disjoint the paths used for replication
should be (it just mentions that they are disjoint). If there's no need to
protect (TI-LFA, etc.) the redundant traffic, can it be assumed that the
traffic will survive a single-link failure on one redundant path?  Single
node? One SR Policy? ??

This topic should be covered in more depth than a sentence in the
Introduction.



...
125 2.2.  Terminology and Conventions
...
137   R-node: Redundancy node participating in the service protection.

[minor] "R-node" is used only once outside of this section -- "redundancy
node" is used almost exclusively.


[major] The concept of "redundancy node" is not defined anywhere.  The next
two terms indicate that there are two types...can a node have both
functions?  [I'm sure it can...  That is the type of detail we need.]


139   Rep node: R-node doing replication.  A network element that
140   replicates incoming packets for parallel delivery.

142   Elm node: R-node doing elimination.  A network element that
143   eliminates duplicates to forward a single copy.

[minor] "Rep node" is used only once outside this section...and "Elm node"
twice.

[I'm pointing out the number of instances because it may be that you don't
need to define these terms.]



...
150   SN: Sequence Number

[minor] "SN" is almost never used. Most of the text uses "sequence number"
or "SeqNum".  Please be consistent.



152 3.  Redundancy Protection in Segment Routing Scenario
...
180   2) When the packet flow arrives at Rep node (a redundancy node
181   configured for replication), each packet is replicated into two or
182   more copies.  Each copy of the packet is encapsulated with a new
183   segment list, which represents different disjoint forwarding paths
184   towards the next R-node.  The disjoint path is provisioned by a
185   controller.

[minor] "replicated into two or more copies"

In this example, the replication is into 2 (not more), right?



...
194   4) The multiple replicas go through different paths until they reach
195   the next redundancy node i.e., the Elm node.  The first received copy
196   of each flow packet is transmitted from Elm node to R2, and the
197   redundant packets are eliminated.

[major nit] "redundancy node i.e., the Elm node"

Some of the uses of "redundancy node" refer to a specific type: replication
*or* elimination, and not both.  In those cases, it may be clearer to the
reader if the specific type is used.



...
202   6) Sometimes, out-of-order packets may occur since service packets
203   are recovered from different forwarding paths.  In this case, the
204   redundancy node or other network nodes downstream to the redundancy
205   node MAY include a reordering function, which is implementation
206   specific and out of the scope of this document, to guarantee in-order
207   delivery of packets.

[major] s/MAY/may

This description is part of an example, so Normative language shouldn't be
used.

The information is important, so it may be better to extract it from the
example. (see more on this below)



...
211   To minimize the jitter caused by random packet loss, the disjoint
212   paths are RECOMMENDED to have similar path forwarding delay.

[major] "RECOMMENDED to have similar path forwarding delay"

This section is written as an example, with this last paragraph providing
Normative (deployment/operational) guidance.

Suggestion: Describe the general operation first and then show the example.
Include any operational guidance in the general text.

BTW, when offering recommendations (especially when Normative), please make
sure to explain the effect of not following the recommendation.  In this
case, an explanation that dissimilar paths may lead to jitter might be a
better formulation, because the Normative language has no interoperability
impact.



214 4.  SRv6 Segment Behavior to Support Redundancy Protection
...
222   Note, that the algorithm used by the Redundancy Functionality is not
223   within the scope of this document.  For example, IEEE Std
224   802.1CB-2017 provides such algoritms.

[minor] Include the reference for 802.1CB.


[nit] s/algoritms/algorithm



226 4.1.  Redundancy Segment Endpoint Behavior

[major] There is significant redundancy (no pun intended! :-/ ) between
this section and §5. Please consolidate.



...
236   Redundancy Segment is the identifier of packets on which service
237   protection needs to be executed on the redundancy node.  It has
238   associated Redundancy Policy(s), instantiation of which provides
239   service protection action(s).  This is similar to the relationship
240   between Binding SID and SR Policy
241   [I-D.ietf-spring-segment-routing-policy], the use of Redundancy
242   Segment triggers the Redundancy Policy instantiation on the
243   redundancy node.

[major] "Redundancy Policy" is used here for the first time, but the
definition appears in §6. Consider moving §6 to be before this section, or
at least add a reference.


[major] "similar to the relationship between Binding SID and SR Policy"

This relationship needs further explanation; it is not enough to say it is
"similar". How? What are the differences?



...
263   For service protection processing, two arguments are needed:

265   1.  Flow-ID (FID): defines which flow the packet belongs to (what is
266       used to determine which Redundancy instance has to be used on a
267       node).  (Note: for example DetNet uses 20 bits for FID [RFC8964].

269   2.  Sequence Number (SN): defines the sequencing information, it is
270       created at the first Redundancy node and used by replication and
271       elimination functionalities.  (Note: for example, DetNet uses the
272       following SN sizes: 0/16/28 bits [RFC8964].

[major] Should the references be to rfc8938 or rfc8939?  rfc8964 is the
"DetNet Data Plane: MPLS" document.


[major] Relationship to DetNet traffic

I know that DetNet/IP can use no encapsulation, which made me wonder
whether what is specified in this document is to be "compatible" with other
DetNet traffic, or is it intended to be non-DetNet traffic?

Then there's draft-ietf-detnet-srv6-svc-protection. What is the
relationship of that draft to this document?  Related to the comments
above, §4.2.1/draft-ietf-detnet-srv6-svc-protection also points at rfc8964
when talking about the SN:

   2.   SeqNum: defines the sequencing information, it is created at the
        DetNet edge node (or by the first PRF node) and used by PEF/POF
        functionalities. Same sizes as for the DetNet MPLS data plane
        are defined for the SRV6 case: 0/16/28 bits [RFC8964].

Note that this document does not define the size of the SN...it only
mentions it as an example (above).



274   In order to eliminate the redundant packets of a flow, the
275   elimination node utilizes sequence number to evaluate the redundant
276   status of a packet.  Note that implementation specific mechanism
277   could be applied to control the amount of state monitored on sequence
278   number, so that system memory usage can be limited at a reasonable
279   level.

[minor] "Note that implementation specific..."

s/.../The mechanism used for elimination is implementation-specific and
outside the scope of this document.


[major] The definition of this functionality adds state to the network.
Specifically, it adds state to a node that is not an ingress node.

rfc8402, the segment routing architecture, talks about the state only being
present at the ingress node and the fact that other nodes have
significantly less state as an advantage.

I would like to see a discussion of the effect of the additional state in
general, not just the security section's discussion of what happens if the
state is exhausted. It should include the effect on the architecture
itself, because once we introduce functionality that differs from the rest
of the architecture, the architecture changes.



281   As elimination node needs to maintain the state of flows, a
282   centralized controller should have a knowledge of elimination nodes
283   capability, and never provision the redundancy policy to redundancy
284   node when the computation result goes beyond the flow recovery
285   capability of elimination node.  The capability advertisement of
286   elimination node will be specified separately elsewhere, which is not
287   within the scope of this document.

[major] "controller should have a knowledge of elimination nodes
capability, and never provision..."

The text above is clearly normative in effect: the controller SHOULD/MUST
know the capabilities and MUST NOT overload. Either explain when exceptions
are acceptable or clearly state that it is a requirement.


[minor] "will be specified separately elsewhere"

s/.../The capability advertisement is outside the scope of this document.



289   The Redundancy SID (RSID) MUST be the last segment in an SR Policy
290   and it is associated with the Redundancy functionality!

[nit] s/!/.



...
309 S01. If (Upper-Layer header type == ( 4(IPv4) OR 41(IPv6) OR
143(Ethernet) ) {

[] From idnits:  ** There are 11 instances of too long lines in the
document, the longest one being 6 characters in excess of 72.


310 S02.   Extract the ARG part of the SID
311 S03.   Remove the outer IPv6 header with all its extension headers
312 S04.   Forward the exposed payload, type and the ARG part to the
Redundancy
313       functionality
314 S05. } Else {
315 S06.    Process as per Section 4.1.1 of RFC8986
316 S07. }

[major] Please find a way to reference rfc8986 in the text so there is a
reference to it.



318 4.2.  SR Policy Headend Behaviors

320   This section describes a set of SRv6 Redundancy Policy Headend
321   [RFC8402] behaviors.

[minor] rfc8986, where the initial Headend Behaviors are defined, is a
better reference.



...
337   When a node "N" receives a packet P=(A, B) identified as a Flow for
338   redundancy.  B is neither a local address nor SID of "N".  It
339   executes the Flow related Redundancy function(s), resulting in one or
340   more member flow (P1=(A, B), P2=(A, B), ...) with related parameters
341   ([Flow-ID1, SeqNum], [Flow-ID2, SeqNum], ...).

[nit] s/member flow/member flows


[nit] Putting the description in a single paragraph makes it less clear.
Consider using a style similar to rfc8986. For example:

   Node "N" receives a packet P=(A, B) identified as a Flow for
   redundancy.  B is neither a local address nor SID of "N".

   Node "N" executes the Flow related Redundancy function(s), resulting
   in one or more member flows (P1=(A, B), P2=(A, B), ...) with related
   parameters ([Flow-ID1, SeqNum], [Flow-ID2, SeqNum], ...).

   ...

   Node "N" is configured with an IPv6 address "T" (e.g., assigned to
   its loopback).

   "N" steers the egress packet P1 into an SRv6 Policy
   with a Source Address T and a segment list SP1=<S11, S12, S13>, where
   S13 is a Redundancy SID (LOC+FUNCT) with 0 as ARG.



343   Note: The number of resulting member flows depends on the
344   configuration of the Flow related function(s).  For example, in case
345   of elimination there is only one member flow.

[] IMHO, it can be confusing to generalize the description of the
redundancy functions and not explain them individually: "this is what
happens when replicating, and this is what happens when eliminating..."
 For example, this note refers to the paragraph above, but the paragraph
below seems to only apply when replicating (the eliminating node wouldn't
add a Redundancy SID), and there's no clarification.


347   Node "N" is configured with an IPv6 address "T" (e.g., assigned to
348   its loopback).  "N" steers the egress packet P1 into an SRv6 Policy
349   with a Source Address T and a segment list SP1=<S11, S12, S13>, where
350   S13 is a Redundancy SID (LOC+FUNCT) with 0 as ARG.



...
355   S01. Push an IPv6 header with its own SRH
356        Set the ARG part of the LAST SID in the segment list

[major] How is the ARG set?  If this behavior is expected to be Normative,
there needs to be some explanation of how so that we can end up with
interoperable implementations.


357   S02. Set outer IPv6 SA = T and outer IPv6 DA to the first SID
358        in the segment list
359   S03. Set outer Payload Length, Traffic Class, Hop Limit, and
360        Flow Label fields
361   S04. Set the outer Next Header value
362   S05. Decrement inner IPv6 Hop Limit or IPv4 TTL
363   S06. Submit the packet to the IPv6 module for transmission to S11

[major] The process above is written from the point of view of having a
single SL (SP1). But the replication requires the packet to be replicated
and encapsulated multiple times...  The text below shows the resulting
encapsulations, but the process is incomplete.


365   After the H.Encaps.R behavior, P1, and P2 (if exists) respectively
366   look like:

368   *  (T, S11) (S13, S12, S11; SL=2) (A, B), note: S13.ARG=Flow-ID1,
369      SeqNum

371   *  (T, S21) (S23, S22, S21; SL=2) (A, B), note: S23.ARG=Flow-ID2,
372      SeqNum

374   The member flow packet is encapsulated unmodified (with the exception
375   of the IPv4 TTL or IPv6 Hop Limit that is decremented).

[minor] "member flow" is used at the start of this section to refer to the
resulting flows, not the original one.



...
396 4.2.3.  H.Encaps.R.L2: H.Encaps.R Applied to Received L2 Frames
...
406   S01. Push an IPv6 header with its own SRH
407        Set the ARG part of the LAST SID in the segment list
408   S02. Set outer IPv6 SA = T and outer IPv6 DA to the first SID
409        in the segment list
410   S03. Set outer Payload Length, Traffic Class, Hop Limit, and
411        Flow Label fields
412   S04. Set the outer Next Header value
413   S05. <N/A>

[minor] No need to include this step at all.



...
439 5.  Meta Data to Support Redundancy Protection

[major] There is significant redundancy (no pun intended! :-/ ) between
this section and §4.1. Please consolidate.


441   To support the redundancy protection function, flow identification
442   and sequence number are added in the packet and further used at
443   redundancy node when the elimination function is executed.  Flow
444   identification identifies one specific flow of redundancy protection,
445   and is usually allocated from centralized controller to SR ingress
446   node or redundancy node in SR network.  Note that flow identification
447   can also be allocated and advertised by redundancy node.  BGP, PCEP
448   or Netconf protocols can facilitate the advertisement and
449   distribution of flow identification among controller and redundancy
450   nodes.  Sequence number distinguishes the packets within a flow by
451   specifying the order of packets.  Unlike the flow identification,
452   which remains constant for a given flow, the sequence number changes
453   with each packet.  It is RECOMMENDED to add the sequence number in
454   forwarding plane as performance and scalability is required.

[nit] s/from centralized controller to SR ingress node or redundancy node
in SR network/from a centralized controller to an SR ingress node or
redundancy node in the SR network


[nit] s/by redundancy node/by the redundancy node


[major] "Flow identification...is usually allocated from centralized
controller...can also be allocated and advertised by redundancy node."

What should the characteristics of the flow IDs be? Should they be globally
unique? I'm asking because if they are not unique, it can lead to flow ID
collision attacks: multiple flows with the same ID end up in the same
elimination node, which could lead to wrong decisions. Having multiple
configuration points may also be an issue.



[major] "It is RECOMMENDED to add the sequence number in forwarding plane
as performance and scalability is required."

When is it ok not to use a sequence number?  When would performance and
scalability not be desirable? Why is it not required?



456   The explicit format of Redundancy SID (RSID) is network addressing
457   design specific.  Redundancy specific parameters are encoded as
458   follows:

460   *  LOC: specifies the redundancy node (same allocation rule applies
461      as for any SRv6-enabled node).

463   *  FUNCT: a single value represents the redundancy function of a
464      redundancy node.

466   *  ARG: Contains the Flow-ID and the Sequence Number parameters.

[major] How many bits are used for the FID and SN?

Examples are provided in §4.1, but that won't result in interoperable
implementations. I appreciate that addressing can be network-specific, but
I would at least expect some general guidance (which could influence
addressing decisions).

For example, if my network uses /96 for LOC+FUNC, are the remaining 32 bits
enough to carry a 20-bit FID (§4.1) + a large enough SN field to support
10Gbps of traffic? How should a wrapping SN be treated?


[major] Given that SRv6 is an IPv6 packet on the wire, why doesn't rfc8939
apply? Specifically, rfc8939 talks about using the IPv6 Flow Label for flow
identification, but this document puts that information in the SID. Also,
rfc8939 is not even mentioned once.



468   Note: if Function=RSID, Arg=0 is also a meaningful value and does not
469   refer to the lack of arguments.

[] I'm lost, please explain how Arg=0 is meaningful to the elimination node.



471   Note2: Encoding the FlowID and SeqNum as Arguments of the SID implies
472   that when the RSID is in the IPv6 DA, the DA changes on a per packet
473   basis for the redundancy protected flow, and it may alter the ECMP
474   hashing.  This can be avoided for example by using additional node
475   specific SIDs before the RSID (e.g., End) or by excluding those bits
476   from ECMP hashing.

[minor] This sounds like a good discussion/example for an Operational
Considerations section.



478 6.  Segment Routing Policy to Support Redundancy Protection

480   Redundancy Policy is a variation of SR Policy to conduct the replicas
481   to multiple disjoint paths for redundancy protection.  It extends SR
482   policy [I-D.ietf-spring-segment-routing-policy] to include more than
483   one active and parallel ordered lists of segments between redundancy
484   node and merging node, and all the ordered lists of segments are used
485   at the same time to steer each copy of flow into different disjoint
486   paths.

[major] rfc9256 states that multiple segment lists can be used for ECMP,
which is not the use in this draft. Given the extension, this document
should provide a full discussion of the changes/requirements/effect of the
use of replication with respect to rfc9256. I would expect a discussion
that mirrors the structure of §2/rfc9256. As is, I believe the Replication
Policy is underspecified.

For example, does the criteria for a Candidate Path to be active change
with the use of a Redundancy Policy? I would expect that more than one
segment list would be required — otherwise, there is no redundancy. It
seems to me that the redundancy use case fits the type of scenario that
draft-ietf-spring-sr-policy-cp-validity applies to (requiring a minimum SL
count). Does eligibility (draft-ietf-spring-sr-policy-eligibility) play a
role here too?


[minor] "between redundancy node and merging node"

Until now, "redundancy node" has been used to refer to both the replication
node and the elimination node; "merging node" is a new term.  Please be
consistent!



488 7.  IANA Considerations

490   This document requires registration of End.R behavior in "SRv6
491   Endpoint Behaviors" sub-registry of "Segment Routing Parameters"
492   registry.

494   IANA maintains The "SRv6 Endpoint Behaviors" sub-registry of the
495   "Segment Routing Parameters" registry.  IANA is requested to make one
496   new assignments from the First Come First Served portion of the
497   registry as follows:

[minor] These two paragraphs are redundant.


[major] I assume there are no implementations.  It is required to add an
implementation description section according to the spring policies.

https://wiki.ietf.org/en/group/spring/WG_Policies



...
503 8.  Security Considerations

505   The introduction of Redundancy Segments and Merging Segments in
506   Segment Routing networks introduces new vectors for security threats
507   that must be carefully mitigated.

[minor] "Merging Segments" are not mentioned anywhere else.


[minor] Please mention here that other Security Considerations apply:
rfc8402, rfc8986, etc..


[major] Also, please take a look at draft-spring-srv6-security. The
considerations there should also apply. Is there anything that was not
mentioned there that this document should explicitly address?



509 8.1.  Packet Duplication

511   Redundancy protection intentionally replicates packets across
512   multiple paths.  Without proper admission control or policy
513   enforcement, an attacker could exploit this mechanism to amplify
514   traffic, overwhelming downstream links or merging nodes.

[minor] The amplification can also magnify denial-of-service attacks if
unauthorized traffic reaches replication nodes. Even if admission control
is mentioned below, it is a risk that should be mentioned since the
replication and elimination functions are separate (i.e., elimination can
fail/be disabled in a rogue node while replication continues).



516   The use of redundancy protection SHOULD be restricted to trusted
517   applications and provisioned via authenticated and authorized
518   controllers (e.g., using BGP with RPKI or PCEP with TLS).  Rate-
519   limiting and flow admission control at the ingress SHOULD be employed
520   to prevent abuse.

[major] "redundancy protection SHOULD be restricted..."

First off, what is the interoperability requirement that needs Normative
language?

When is it ok not to restrict its use? IOW, what is the downside of
allowing other types of applications? BTW, what is a "trusted" application?

When is it ok not to follow the provisioning recommendation?

I don't see a direct relationship between using RPKI and assuming that the
controller is "authenticated and authorized" -- much less so if the
operations are within an SR domain, completely within an AS.


[major] "...SHOULD be employed to prevent abuse"

When is it ok not to use them? Why is the use of rate-limiting and flow
admission control not required?



522 8.2.  Sequence Number Spoofing

524   The merging node relies on sequence numbers to de-duplicate packets.
525   An attacker that can inject or manipulate these sequence numbers
526   could cause legitimate packets to be dropped or reordered.

528   Redundancy Segments MUST be deployed only within trusted SR domains.

[] True (and already specified elsewhere), but this is not a mitigation for
an internal attacker (draft-ietf-spring-srv6-security).



530 8.3.  Information Disclosure
...
536   Such information SHOULD NOT be exposed outside the trusted SR domain.
537   Control-plane interactions involving Redundancy Segments SHOULD be
538   encrypted and authenticated (e.g., BGP with TCP-AO, PCEP over TLS).

[major] "SHOULD NOT be exposed outside the trusted SR domain"

When is it ok to expose this information? Why isn't the behavior required,
in line with rfc8402?


[major] "Control-plane interactions involving Redundancy Segments SHOULD be
encrypted and authenticated (e.g., BGP with TCP-AO, PCEP over TLS)."

I understand the additional threats introduced, but are these segments so
different from others that they require control-plane encryption and
authentication?  Keep in mind that these would not be the only segments
advertised using these control protocols, so the recommendation would
extend to *everything*—which is not something this document can do and is
not required or recommended in other SR documents.

Also, rfc8402 already has some related text:

   Therefore, by default, the explicit routing information MUST NOT be
   leaked through the boundaries of the administered domain.  Segment
   Routing extensions that have been defined in various protocols, leverage
   the security mechanisms of these protocols such as encryption,
   authentication, filtering, etc.



540 8.4.  State Exhaustion at Redundancy Node

542   Redundancy nodes with elimination functionality need to maintain
543   state (e.g., sequence windows, buffering) for each redundancy-
544   protected flow.  An attacker might attempt to create many such flows
545   to exhaust memory or processing capacity.

547   Redundancy nodes SHOULD limit the number of concurrent redundancy
548   flows per source.  Idle timeout mechanisms MUST be implemented to
549   garbage-collect stale state.

[major] "SHOULD limit the number"

When is it ok not to limit the number? Why is this behavior not required?

How should a node decide which flows not to replicate? Some guidance should
be given.

Note that the problem is framed as an issue seen in the elimination node,
but the node that can limit the number of flows is the replication node.
 §4.1 discusses the controller considering the capabilities of the
elimination nodes, but this may not prevent exhaustion at the elimination
node if the attacker can exploit the setup...

Among other things, an attacker could create many bogus FIDs, many
partially active flows, and intentionally sparse sequence numbers.  The
attacker could also take the form of a rogue or subverted replication node.


[major] "Idle timeout mechanisms MUST be implemented..."

Where? What should be the default?


[major] About the state maintained by the elimination nodes.

Besides specifics on flow timeout, the document should also be explicit
about reboot behavior, scale implications, and what happens if elimination
state is lost.

The text above mentions impact on "memory or processing capacity", but it
is not explicit about the effect on the flows/network. For example, if a
node is overwhelmed, is the assumption that it would stop processing
packets or that it would stop eliminating duplicates?  In both cases, what
is the effect?

These are not protocol issues but operational ones. This and some of the
other items I pointed to above could benefit from a dedicated Operational
Considerations section (see also draft-ietf-opsawg-rfc5706bis).


[major] State exhaustion is an issue. However, replication also increases
bandwidth utilization, forwarding load, etc. (even at transit nodes). These
potential issues should also be mentioned. These are mostly operational
security issues, so think about a separate Operational Considerations
section.


[major] Replay attacks are not discussed. A rogue node, either the headend
or a transit node, can cause pathological reordering, intentionally delay
packets, or duplicate packets to arrive much later. Depending on the
elimination window and the timeout, this can force more state to be
retained, trigger false elimination (or allow additional packets), increase
buffering, etc. Please also discuss some of that.


[major] Throughout the document, it is assumed that all the provisioning is
done by a central controller -- that is ok. However, this new functionality
creates new threats. Specifically, if communication with the controller is
compromised, the attacker can redirect traffic, disable redundancy, and
more.

These threats are not necessarily new to the SR control plane, but they are
new in the context of the new functionality, and they should at least be
recognized. Proper wording that points back to other SR documents should be
included.



...
568 11.  Appendix A.  Example
...
587    N: non-SRv6 IPv6 node
588    N: SRv6-capable node

[minor] "N" can't be both.



...
627   *  Node R1, which is an SRv6-capable Redundancy node, identifies the
628      flow the packet belongs to.  As replication is configured for the
629      given flow, R1 performs the replication action and intends to send
630      the packet to the next Redundancy nodes (E5 and R2).  These nodes
631      are reachable via SRv6, so R1 performs H.Encaps.R(.Red) on the
632      replicas with a path specific SRH.  The argument part of the End.R
633      SID involves the Flow-ID and the SeqNum.  Specifically, one
634      replica is sent on link-1 towards E5 (2001:db8:L:1::,
635      2001:db8:K:3:X51::) (2001:db8:K:5:P:arg::, 2001:db8:K:3:X51::,
636      SL=1, NH = IPv6) (2001:db8:src::1, 2001:db8:dst::1, NH = UDP)(UDP
637      payload) and the other replica is sent on link-2 towards R2
638      (2001:db8:L:1::, 2001:db8:K:2:P:arg::, NH = IPv6)
639      (2001:db8:src::1, 2001:db8:dst::1, NH = UDP)(UDP payload).

[] To make the example more readable, separate each replica in its own
line...and add any necessary explanation (for example, "the other replica"
doesn't have an SRH).



...
667   *  Node E5, which is an SRv6-capable Redundancy node, identifies the
668      packets as targeted to the local redundancy function.  E5 performs
669      the decapsulation and forwards the payload and the ARG part to the
670      redundancy functionality.  The redundancy function identifies the
671      flow the packet belongs to.  As elimination is configured for the
672      given flow, the elimination action is performed on the packets
673      received over Link3 and Link7.  E5 intends to send the packet to
674      the next redundancy node (E6), which is reachable via SRv6, so E6
675      performs H.Encaps.R(.Red) with a path specific SRH.  The argument
676      part of the End.R SID involves the Flow-ID and the SeqNum.
677      Specifically, the replica received first is sent on link-6 towards
678      E6 (2001:db8:L:5::, 2001:db8:K:6:P:arg::, NH = IPv6)
679      (2001:db8:src::1, 2001:db8:dst::1, NH = UDP)(UDP payload).

[] E5 can perform both replication and elimination. How does a replication
node determine which action to take, or if it should take one or not?

I'm thinking of R2. The text above, when talking about R2, says that
"replication is configured" -- does this mean that replication and/or
elimination must be configured at each redundancy node for every flow? In
this example, R2 receives a replicated packet, but it doesn't perform
elimination.

I'm not sure if this management/configuration requirement is explicitly
mentioned in the document.



...
700 12.1.  Normative References

702   [I-D.ietf-spring-segment-routing-policy]
703              Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
704              P. Mattes, "Segment Routing Policy Architecture", Work in
705              Progress, Internet-Draft, draft-ietf-spring-segment-
706              routing-policy-22, 22 March 2022,
707              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
708              segment-routing-policy-22>.

[major] Update the reference to rfc9256.



...
724   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
725              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
726              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
727              <https://www.rfc-editor.org/info/rfc8754>.

[minor] This reference is not used.



729   [RFC8964]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
730              S., and J. Korhonen, "Deterministic Networking (DetNet)
731              Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
732              2021, <https://www.rfc-editor.org/info/rfc8964>.

[minor] As used, this reference can be Informative.  See the comments in
§4.1.



...
740 12.2.  Informative References
...
749   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
750              "Deterministic Networking Architecture", RFC 8655,
751              DOI 10.17487/RFC8655, October 2019,
752              <https://www.rfc-editor.org/info/rfc8655>.

[minor] This reference is not used.

[EoR-07]