Hi Sasha, many thanks for your specific questions.
Before answering them two related notes as background information: - This specific figure intends to show the high-level operation of Redundancy Protection. All the details of the packet processing are described in the annex example for a complex network scenario. The annex-example has been “artificially” made more complex to be able to explain the various aspects. - Redundancy protection needs a pre-design, where replication/elimination nodes are carefully selected. One gets the best service protection with the widest coverage, i.e., implementing replication and elimination at the edge nodes, but there are always topology specific pros/cons. Answers regarding the questions: Q1 - Rep node awareness: Neither R1 nor R2 need to be aware of the existence of the replication node. R1 only needs to drive the traffic over the Rep node, but the Rep node operation is local on the node. R2 is an egress PE node it simple receives the flow, it is not aware how the flow was forwarded over the network. It is the role of an entity (e.g., an SDN controller) to design properly the Redundancy Protection and ensure that R1 forwards the flow, that uses the Redundancy Protection, over the Rep node and configure the Rep node with the replication action for a given flow. Q2 - Services pass thru the specific replication node Setting up appropriate explicit path ensures that the flow goes over the Rep node. Explicit paths can be set up, e.g., by an SDN controller providing the appropriate SID list to be used for a given explicit path. Q3 - Service instance awareness The Rep node is not aware of the service instances. It acts on a flow level. The first R-node (here the Rep node) is configured with the ingress flow specifics (e.g., 6-tuple of the served flow). FIDs used for the egress member flows are allocated by the downstream R-nodes (or a controller entity). Regarding scalability, the Rep node holds the states only for the flows that are using its Redundancy functionality. Aggregation of flows are possible, so the number of hold states can be mitigated. Note2 - ECMP Right, agree. Controlling the behavior of ECMP in transient nodes can be problematic. Removing that part of the text seems to be a good improvement. Let me know if further clarification is needed or I have misinterpreted something. Many thanks Bala'zs From: Alexander Vainshtein <[email protected]> Sent: Wednesday, July 22, 2026 11:01 AM To: [email protected] Cc: [email protected]; BESS <[email protected]> Subject: draft-ietf-spring-sr-redundancy-protection Hi, I read the draft and I have a couple of questions/comments I would like to share with you. Figure 1 in the draft (copied below for convenience) shows Replication and Elimination nodes as being different from the ingress and egress nodes R1 and R2 at the edge of the SRv6 domain. | | |<--------------- SRv6 Domain ---------------->| | | | +-----+ | | +-----+ R3 +-----+ | | | +-----+ | | +-----+ +--+--+ +--+--+ +-----+ -------+ R1 +--------+ Rep | | Elm +-------+ R2 +------- +-----+ +--+--+ +--+--+ +-----+ | +-----+ | +-----+ R4 +-----+ +-----+ One (probably typical) use case could be that R1 and R2 are Provider Edge (PE) nodes running multiple instances of BGP-based services on top of the SRv6 underlay as defined in RFC 9252. In this case service SIDs would be advertised using MP-BGP and.any intermediate nodes would not be aware about any specific service instances and their associated Service SIDs. Now my questions: Question 1: How can R1 and R2 be aware of the existence of the Replication node? Question 2: How can the ingress PE guarantee that the desired services pass thru the specific replication node? Question 3: How would the repllcaton node be aware of each of these service instances so that theyir respective packetd could be encapsulated with a service-specific FIDs? And how would this affect scalability of the proposed solution? Obviously these questions would become moot if the Replication and Elimination nodes are also the Ingress and Egress PEs of the services. I would also like to comment comment on Note 2 in Section 3.3 that says: Note2: Encoding the FID and SeqNum as Arguments of the SID implies that when the RSID is in the IPv6 DA, the DA changes on a per packet basis for the redundancy protected flow, and it may alter the ECMP hashing. This can be avoided for example by using additional node specific SIDs before the RSID (e.g., End) or by excluding those bits from ECMP hashing. I have serious doubts about the marked, because behavior of ECMP in transient nodes cannot be controlled. Your feedbck would be highly appreciated,. Regards, and lots of thanks in advance, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
