[Detnet] Re: WG Last Call: draft-ietf-spring-sr-redundancy-protection-07 (Ends 2026-07-06)

[Balázs Varga A <[e-mail]>]

Hi Fabian,

 

Many thanks for your review and precise comments. We will make the following changes in the 

next version of the document.

 

1, Introduction

OLD TEXT

   … On the

   elimination network node, the multiple copies are received, redundant

   packets eliminated, and only a single copy of the packet is

   forwarded, the redundant copies are eliminated.

NEW TEXT

   … On the

   elimination network node, the multiple copies are received, redundant

   packets eliminated, and only a single copy of the packet is

   forwarded.

END

 

2, Terminology, 

Right, we intend to keep the R-node term and will review its usage with Luis (shepherd of the draft).

For example, Section 3. can gain from using the term. 

 

3, Section 3.3

Right, your proposed pointer is added.

OLD TEXT

      This packet meta data is included on each of the replicas

      at the redundancy node.

NEW TEXT

      This packet meta data is included on each of the replicas

      at the redundancy node (see Section 5. for details).

END

 

4, Section 3.6

Right, reordering make sense after the Elimination nodes.

OLD TEXT

   … In this case, the

   redundancy node or other network nodes downstream to the redundancy

   node MAY include a reordering function, which is implementation

   specific and out of the scope of this document, to guarantee in-order

   delivery of packets.

NEW TEXT

   … In this case, the

   Elm node or other network nodes downstream to the R-node

   MAY include a reordering function, which is implementation

   specific and out of the scope of this document, to guarantee in-order

   delivery of packets.

END

 

5, Section 4.1, Typo fixed.

OLD TEXT

   … Note that implementation specific mechanism …

NEW TEXT

   … Note that an implementation specific mechanism …

END

 

6, Section 4.2.1 (S01)

Right, text is modified with as per your suggestion.

OLD TEXT

   S01. Push an IPv6 header with its own SRH

             Set the ARG part of the LAST SID in the segment list

NEW TEXT

   S01. Push an IPv6 header with its own SRH

             Set the ARG part of the LAST SID in the segment list

             with FID and SN 

END

 

7, Section 4.2.1 (S04)

Next header is flow specific. Flows can be IPv4 or IPv6. We intended to describe it

similar to “H.Encaps” definition in RFC8986.

 

8, Section 5. 

Number of bits for Flow-ID and SeqNum. 

Yes, it is intentionally open. The explicit format of Redundancy SID (RSID) is network 

addressing design specific. DetNet specific example can be found in  Section 4.2.1 in 

https://datatracker.ietf.org/doc/draft-ietf-detnet-srv6-svc-protection/

 

Again, many thanks for your detailed review and suggestions. 

 

Cheers

Bala’zs

 

From: Fabian Ihle <[e-mail]> 
Sent: Sunday, June 28, 2026 1:50 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-spring-sr-redundancy-protection-07 (Ends 2026-07-06)

 

Hi all, I've read the draft and support the publication of the draft. I have some more nits on the current state:

*	In the introduction, the sentence "[...], the redundant copies are eliminated" is redundant with "redundant packets are eliminated" in the line above.
*	Terminology section introduces R-node as abbreviation for Redundancy node, but the document does not make use of it. I suggest either removing the abbreviation or using it consistently. Also sometimes, capitalization is inconsistent.
*	Section 3.3: "This packet meta data is included on each of the replicates" could clarify more about how those are encoded (or just put a forward pointer to Section 5).
*	Section 3.6 proposes that the redundancy node or other networks downstream may include a reordering node. But this also includes the replication node by the definition of redundancy nodes in the draft, I think having a reordering function at the replication node doesnt make sense?
*	Section 4.1: "Note that **a** implementation specific [...]"
*	The algorithm in 4.2.1 would benefit from

*	S01: To what is the ARG actually set? --> Flow ID and Sequence number I guess?
*	S04: Outer Next Header Value should always be set to IPv6 right?

*	Section 5: How many bits are there for the Flow ID, and for the sequence number? Should this maybe be defined here as well, or is that intentionally open?

Best, Fabian

 
-----Original Message-----
From: Alvaro Retana via Datatracker  <mailto:[e-mail]> <[e-mail]>
Sent: Friday, June 19, 2026 6:30 PM
To: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> 
Subject: WG Last Call: draft-ietf-spring-sr-redundancy-protection-07 (Ends 2026-07-06)
 
This message starts a WG Last Call for:
draft-ietf-spring-sr-redundancy-protection-07
 
This Working Group Last Call ends on 2026-07-06
 
Abstract:
   Redundancy Protection is a generalized protection mechanism to
   achieve high reliability for service provided in Segment Routing
   networks.  The mechanism uses the "Live-Live" methodology, i.e.,
   multiple copies of the data packets are sent on different paths to
   provide protection.  This document introduces one new SRv6 Segment
   Endpoint Behavior to provide replication and elimination functions on
   specific network nodes by leveraging SRv6 Network Programming
   capabilities.
 
File can be retrieved from:
 
Please review and indicate your support or objection to proceed with the publication of this document by replying to this email keeping [e-mail] <mailto:[e-mail]>  in copy. Objections should be explained and suggestions to resolve them are highly appreciated.
 
Authors, and WG participants in general, are reminded of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [1].
Appropriate IPR disclosures required for full conformance with the provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
Sanctions available for application to violators of IETF IPR Policy can be found at [3].
 
Thank you.
 
[1] https://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/
 
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-redundancy-protection/
 
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-redundancy-protection-07
 
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-sr-redundancy-protection-07

-- 
Fabian Ihle
Universität Tübingen
Fachbereich Informatik Lehrstuhl Kommunikationsnetze
Wilhelm-Schickard-Institut für Informatik
Sand 13, 72076 Tübingen 
 
Raum: B303
Telefonnr.: [phone]
E-Mail: [e-mail] <mailto:[e-mail]> 
Internet: uni-tuebingen.de