Skip to main content

Last Call Review of draft-ietf-spring-sr-replication-segment-10

Request Review of draft-ietf-spring-sr-replication-segment
Requested revision No specific revision (document currently at 19)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2022-11-14
Requested 2022-10-26
Requested by Jim Guichard
Authors Daniel Voyer , Clarence Filsfils , Rishabh Parekh , Hooman Bidgoli , Zhaohui (Jeffrey) Zhang
I-D last updated 2022-11-14
Completed reviews Opsdir Last Call review of -14 by Sarah Banks (diff)
Genart Last Call review of -14 by Thomas Fossati (diff)
Tsvart Last Call review of -14 by Wesley Eddy (diff)
Secdir Last Call review of -15 by Mohit Sethi (diff)
Rtgdir Last Call review of -10 by Ines Robles (diff)
Assignment Reviewer Ines Robles
State Completed
Request Last Call review on draft-ietf-spring-sr-replication-segment by Routing Area Directorate Assigned
Posted at
Reviewed revision 10 (document currently at 19)
Result Has issues
Completed 2022-11-14
I am the assigned Rtg reviewer for this draft. Please treat these comments just
like any other last call comments.

Document: draft-ietf-spring-sr-replication-segment-10
Reviewer: Ines Robles
Review Date: 2022-11-14


This document (with intended status Standards Track) describes the SR (Segment
Routing) Replication segment for Multi-point service delivery. A SR Replication
segment allows a packet to be replicated from a Replication Node to Downstream

The document mention two implementations. An example is described in Appendix A.

Major issues: None

Minor issues:

1- Requirements Language section should add RFC 8174, i.e. "...."NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here."

2- There is no terminology section. It would be nice to have a terminology
section where inform to the reader which document to read to understand the
terminology not defined in the document e.g. "..the operations NEXT, PUSH are
defined in RFC8402 and the POP operation in RFC...; H.Encaps.Red is defined in

3- Page 3: "Replication-ID can be a 32-bit number, but it can be extended or
modified as required... " -> to which limit can be extended?

4- Question: since the replication state of the nodes can change over time. Is
it possible that in some particular circumstances this change could trigger a
loop in the replication segment? or this is not possible?

5- The security considerations states: "There are no additional security risks
introduced by this design". Additional to what features? This is not clear to
me. Perhaps it would be nice to rephrase it to something like: "The security
considerations outlined in RFC 8402, RCF... also applies to this document"?

Nits/editorial comments:

6- Page 7: all the Must and SHOULD... => all the MUST and SHOULD?

7- Page 11- Figure 1: It would be nice if the caption of the figure could be

8- Page 13 Paragraph 8 and 9: End.Replcate => End.Replicate?

Thanks for this document,