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 <[email protected]>
Sent: Sunday, June 28, 2026 1:50 PM
To: [email protected]; [email protected]
Cc: [email protected]
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:[email protected]>
<[email protected]>
Sent: Friday, June 19, 2026 6:30 PM
To: [email protected]
<mailto:[email protected]> ;
[email protected]
<mailto:[email protected]> ; [email protected]
<mailto:[email protected]> ; [email protected] <mailto:[email protected]>
Cc: [email protected] <mailto:[email protected]>
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 [email protected]
<mailto:[email protected]> 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.: +49 7071 29-70545
E-Mail: [email protected] <mailto:[email protected]>
Internet: uni-tuebingen.de
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
