Balázs:
Hi!
You didn't reply to the inline comments, so I had to chase the changes one
by one... :-( I'm replying only to the high-level issues I raised at the
beginning.
Thanks!
Alvaro.
On July 15, 2026 at 2:44:08 AM, Balázs Varga A wrote:
...
> > 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)
> It is optional. Text was updated.
This is the new text in the Introduction:
=====
Depending on the Service Level Objective of a service and the network
characteristics (topology, link/node availability, Bit Error Rate of
links, etc.) redundancy protection can be used alone or together with
other protection mechanisms like TI-LFA. Detailed design rules of
redundancy protection (e.g., location of replication and elimination
functions, number of used protection paths, routes of protection
paths) are scenario-specific and outside the scope of this document.
=====
[minor] Add a reference for TI-LFA.
[major] Assuming that the second sentence is referring to the possible use
of redundancy protection with path protection, it is ok to leave *design
rules* out of scope.
OTOH, I would like to see *design guidance*. §7 provides some (scattered)
considerations and constraints about the placement of the R-nodes (for
example, resource consumption in §7.3), but it doesn't cover general design
guidance...for example:
What about topological placement? I know this is scenario/topology-
specific, but I would assume that general guidance could still apply:
replicate as close to the source as possible...eliminate as close to the
destination as possible... IOW, if we apply the function too close (with
only a few nodes between the functions) than it may not be
effective/efficient; i.e., maximize physical separation. Consider the
failure domains: locating two R-nodes in the same SRLG/failure domain
defeats the purpose of replication.
I understand that these may be "obvious" (good engineering practice).
Nonetheless, please offer guidance.
> > 2. Operational/Deployment guidance is present in several parts of the
> > draft. Consider a standalone Operational Considerations section (see
> > draft-ietf-opsawg-rfc5706bis).
> New section was added.
Some comments on the new section:
=====
750 7. Operational Considerations
...
760 7.1. Installation and Initial Setup
762 Redundancy protection MUST operate with reasonable defaults:
[major] This section affirms the defaults defined elsewhere...the use of
"MUST operate" doesn't make sense from a Normative point of view: what is
required; that the system operate?
Suggestion>
Redundancy protection operational defaults are as follows:
764 * Redundancy Protection function: R-nodes default to ordinary IPv6
765 processing (i.e., without any redundancy protection actions on
766 packets) until explicitly configured with an RSID and the related
767 Redundancy Policy.
769 * FID Field Size: Default to 20 bits as specified in Section 3.2.
771 * SeqNum Field Size: Default to 16 bits as specified in
772 Section 3.2., and supporting 28 bits for advanced scenarios.
[major] §3.2 doesn't specify a default for the FID/SeqNum; it indicates
which values are required (even if only one for the FID).
Solution: add text in §3.2 indicating which is the default.
[[ **
Aside, but related -- text from §3.2:
268 The minimum number of bits needed for FID and SeqNum are dependent on
269 the network scenario and the characteristics of the served flows. As
270 the size of these parameters directly impacts scalability, this
271 document list values an implementation MUST support. Other parameter
272 sizes MAY be supported if it fits within the selected network
273 addressing design.
[major] s/this document list values an implementation MUST support./this
document list values an implementation is required to support.
The Normative statement comes later when the size of the FID/SeqNum are
specified.
[major] "Other parameter sizes MAY be supported if it fits within the
selected network addressing design."
s/MAY be supported/MAY be used
Also, add a short operational item noting that several nodes in the network
are required to support these other parameter sizes if they are used.
** ]]
...
828 7.4. Security Operations
...
841 * Management Access Control: needs to use strong authentication,
842 encrypted transport (TLS), and role-based access control (RBAC)
843 for all management interfaces.
[minor] Add references.
...
=====
> > 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.
> It defines the usage of RSID in the DetNet service sub-layer.
That (one sentence) didn't really answer my question -- or I just don't
understand.
My two questions were:
(1) 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?
(2) 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.
The new Redundancy Policy section has a reference to rfc8939:
=====
3.3. Redundancy Policy
A Redundancy SID MUST have a related Redundancy Policy. The
Redundancy Policy MUST contain entries for each member flow for which
the R-node provides redundancy protection using the given RSID. Each
entry of the Redundancy Policy MUST contain the flow-specific actions
and their parameters.
The following summarizes the minimum set of information that is
needed in the Redundancy Policy entries:
* Ingress member flow(s) identification information (e.g., FID).
* Redundancy action-specific parameters (e.g., RedInst identifier,
Action pipeline, Action type, SeqNum length, Algorithm).
* Egress member flow(s) identification information (e.g., RSID+FID
used by the downstream R-node).
* Egress member flow(s) redundancy path parameters (e.g., ordered
list of segments associated with a member flow).
The first and last R-nodes need additional information elements:
* Ingress flow matching information on the first R-node (e.g., 5-
tuple of the served original flow).
* Egress forwarding information on the last R-node (e.g., which
VRF/VSI to use for forwarding).
Flow matching options are defined, for example, in [RFC8939]. They
can be used for ingress flow matching on the first R-node.
The use of an SR Policy, as described in [RFC9256], to define an
egress member-flow protection path is outside the scope of this
document.
=====
[] I find this text confusing/misleading because it seems to draw a
relationship between the ingress flow identification in rfc8939 ("Flow
matching options are defined...in [RFC8939]. They can be used for ingress
flow matching on the first R-node.") and the ingress flow identification
used with the Redundancy SID ("Ingress member flow(s) identification
information (e.g., FID)."). They feel related, but they are not. Also,
the information elements contain a mention of "5-tuple of the served
original flow", when rfc8939 uses 6-tuple-based flow identification.
Suggestion>
* Ingress flow matching information on the first R-node (e.g.,
flow-identification fields as specified in RFC 8939).
...
[Insert after the paragraph mentioning rfc8939.]
rfc8939 flow identification is used to classify the original
ingress flow at the first R-node; the FID defined in this document
is a separate, locally significant identifier for a member flow and
is not defined by rfc8939.
I know the text elsewhere says the FID is locally significant, but a
reminder can't hurt.
...
> > 5. What should be the characteristics of the FIDs? What happens if
there
> > are collisions? (line 443)
> FIDs are locally unique on the R-node. Text was updated.
The updated text is from §3.2:
217 FID identifies one specific member flow on an R-node and has local
218 significance. The FID value is allocated by the receiving R-node,
219 therefore an upstream R-node must place the downstream R-node's FID
220 in the RSID. Allocation methods and signalling of FID values are
221 outside the scope of this document. They can be allocated for
222 example, by a centralized controller or can be allocated and
223 advertised by the R-node. BGP, PCEP or NETCONF protocols can
224 facilitate the advertisement and distribution of flow identification
225 information among controllers and R-nodes. FID MUST be included in
226 the RSID as an argument.
Part of my original concern still exists in this text: "They can be
allocated for example, by a centralized controller or can be allocated and
advertised by the R-node."
Multiple configuration sources allocating non-unique IDs could 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.
...
> > 7. Expand on the concept of a Redundancy Policy and how it relates to
> > rfc9256 (line 480).
> Text was updated, it has a dedicated section 3.3.
>From §3.3: "The use of an SR Policy, as described in [RFC9256], to define
an egress member-flow protection path is outside the scope of this
document." But the original text in -07 said this:
Redundancy Policy is a variation of SR Policy to conduct the replicas
to multiple disjoint paths for redundancy protection. It extends SR
policy [I-D.ietf-spring-segment-routing-policy] to include more than
one active and parallel ordered lists of segments between redundancy
node and merging node, and all the ordered lists of segments are used
at the same time to steer each copy of flow into different disjoint
paths.
It mentioned both that the Redundancy Policy is a "variation of SR Policy"
and that it "extends SR policy"...but now rfc9256 is out of scope. ???
...
> > 9. Several threats have not been addressed in the Security
Considerations
> > section (line 503). Also, consider draft-spring-srv6-security.
> Section was updated.
I had some other comments in this section that I don't think were
addressed; repeating here -- they could be addressed in either the Security
or Operational Considerations section:
(a) [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?
(b) [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.
On July 15, 2026 at 2:44:08 AM, Balázs Varga A ([email protected])
wrote:
Dear Alvaro,
Many thanks for the detailed review.
We have created an update of the draft. It includes the comments received
during WGLC.
All Your major and minor comments were addressed. Again, thanks for the
details and the
clear formulation of your suggestions, they helped a lot to improve the
document.
The changes in the draft have not affected the technical details of the
solution, however
they helped to make clear many implicit statements and spell them out
explicitly.
Based on these comments major updates of the draft are:
- Section 3. was restructured to contain all building blocks of the
Redundancy Protection.
The former Section 5. (Meta Data) and Section 6. (Redundancy Policy) were
integrated here.
- Section 3.3 (Redundancy Policy) was improved with an explicit list of
information that is
needed in the Redundancy Policy entries.
- New section (6. Implementation Description) was added.
- New section (7. Operational Considerations) was added to describe
operational aspect.
- Section 8. (Security Considerations) were extended and clarifications
were added.
- Reactions to Your numbered list are inline below.
The new version will be uploaded when upload is re-opened before the
meeting (i.e., Sunday).
In the meantime, you can find it here:
https://drive.google.com/drive/folders/1t-bodD468n4nI4uUkJQFnXD_QqpcKdn8?usp=sharing
Many thanks & Cheers
Bala'zs (and the Co-Authors/Contributors)
-----Original Message-----
From: Balázs Varga A
Sent: Tuesday, July 7, 2026 11:59 AM
To: 'Alvaro Retana' <[email protected]>;
[email protected]
Cc: [email protected]; [email protected]; [email protected]; Luis M.
Contreras <[email protected]>
Subject: RE: Chair Review of draft-ietf-spring-sr-redundancy-protection-07
(WGLC)
Dear Alvaro,
Many thanks for the detailed review.
We will come back soon with suggested changes/improvements.
The new version will be uploaded, when upload is re-opened before the
meeting.
Thanks
Bala'zs
-----Original Message-----
From: Alvaro Retana <[email protected]>
Sent: Friday, July 3, 2026 11:52 PM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]; Luis M.
Contreras <[email protected]>
Subject: Chair Review of draft-ietf-spring-sr-redundancy-protection-07
(WGLC)
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)
<VBalazs> It is optional. Text was updated.
2. Operational/Deployment guidance is present in several parts of the
draft.
Consider a standalone Operational Considerations section
(see draft-ietf-opsawg-rfc5706bis).
<VBalazs> New section was added.
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.
<VBalazs> It defines the usage of RSID in the DetNet service sub-layer.
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).
<VBalazs> From the segment routing architecture perspective R-nodes are
ingresss node for the served member flows. Text was updated.
5. What should be the characteristics of the FIDs? What happens if there
are
collisions? (line 443)
<VBalazs> FIDs are locally unique on the R-node. Text was updated.
6. Provide guidance about the size of the FID and SN (line 466).
<VBalazs> Text was updated with size requirements.
7. Expand on the concept of a Redundancy Policy and how it relates to
rfc9256 (line 480).
<VBalazs> Text was updated, it has a dedicated section 3.3.
8. An Implementation Description section is needed (line 494).
<VBalazs> New section was added.
9. Several threats have not been addressed in the Security Considerations
section (line 503). Also, consider draft-spring-srv6-security.
<VBalazs> Section was updated.
Please take these comments with others that you may receive during the
WGLC.
Thanks!
Alvaro.
...
See the rest of the message:
https://mailarchive.ietf.org/arch/msg/spring/sMJEvVO_i9DBC5dgbZRON4WvnR0/
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
