* 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
o S01: To what is the ARG actually set? --> Flow ID and Sequence
number I guess?
o 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<[email protected]> Sent: Friday, June 19, 2026 6:30 PM To:[email protected];[email protected];[email protected];[email protected] Cc:[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 [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] Internet: uni-tuebingen.de
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
