Hi Alvaro, I am really sorry about the confusions. I expected (wrongly) that a diff provides the resolution of comments. But right, there were too many changes in the document. I will come back to You with detailed reactions to the comments below. Many Thanks Bala’zs
From: Alvaro Retana <[email protected]> Sent: Tuesday, September 22, 2026 5:06 PM To: [email protected]; Balázs Varga A <[email protected]> Cc: Luis M. Contreras <[email protected]>; [email protected]; [email protected]; [email protected] Subject: RE: Chair Review of draft-ietf-spring-sr-redundancy-protection-07 (WGLC) 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]<mailto:[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]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Luis M. Contreras <[email protected]<mailto:[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]<mailto:[email protected]>> Sent: Friday, July 3, 2026 11:52 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Luis M. Contreras <[email protected]<mailto:[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]
