Many thanks Bala'zs, While functionally they are equivalent, the proposed new text is better in my opinion (more precise and same format as RFC8986.
Cheers, Pablo From: Balázs Varga A <[email protected]> Date: Thursday, 12 February 2026 at 17:15 To: 'SPRING WG' <[email protected]> Cc: DetNet WG <[email protected]> Subject: [Detnet] Finetuning End.R description in draft-ietf-spring-sr-redundancy-protection Hi, the draft's technical content seems to be quite stable. Feedback from the WG on one possible improvement would be highly appreciated. In order to make the draft's text similar to RFC8986 format the following changes proposed in section 4.1. "Redundancy Segment Endpoint Behavior": --- OLD TEXT S01. When an SRH is processed { S02. If (Segments Left != 0) { S03. Send an ICMP Parameter Problem message to the Source Address with Code 0 (Erroneous header field encountered), and Pointer set to the Segments Left field, interrupt packet processing and discard the packet S04. } S05. Extract the ARG part of the SID S06. Remove the outer IPv6 header with all its extension headers S07. Forward the exposed payload and the ARG part to the Redundancy functionality S08. } --- NEW TEXT S01. When an SRH is processed { S02. If (Segments Left != 0) { S03. Send an ICMP Parameter Problem message to the Source Address with Code 0 (Erroneous header field encountered), and Pointer set to the Segments Left field, interrupt packet processing and discard the packet S04. } S05. Proceed to process the next header in the packet S06. } When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.R SID, N does the following: S01. If (Upper-Layer header type == ( 4(IPv4) OR 41(IPv6) OR 143(Ethernet) ) { S02. Extract the ARG part of the SID S03. Remove the outer IPv6 header with all its extension headers S04. Forward the exposed payload, type and the ARG part to the Redundancy functionality S05. } Else { S06. Process as per Section 4.1.1 of RFC8986 S07. } --- END OF CHANGE The change would address the followings: - similar format used for the definition of the End.R behavior as the format used in RFC8986 - more clear description of the processing of the Upper-Layer header Any comments are welcome. Thanks & Cheers Bala'zs Ps: this draft impacts DetNet WG as well on using an SRv6 data plane for DetNet, so the DetNet list also cc-ed.
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
