Skip to main content

Last Call Review of draft-ietf-spring-sr-replication-segment-14
review-ietf-spring-sr-replication-segment-14-tsvart-lc-eddy-2023-06-16-00

Request Review of draft-ietf-spring-sr-replication-segment
Requested revision No specific revision (document currently at 19)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2023-06-19
Requested 2023-06-05
Authors Daniel Voyer , Clarence Filsfils , Rishabh Parekh , Hooman Bidgoli , Zhaohui (Jeffrey) Zhang
I-D last updated 2023-06-16
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 Wesley Eddy
State Completed
Request Last Call review on draft-ietf-spring-sr-replication-segment by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/V-FNQgs4HKk61HvPray1XUvKUug
Reviewed revision 14 (document currently at 19)
Result Almost ready
Completed 2023-06-16
review-ietf-spring-sr-replication-segment-14-tsvart-lc-eddy-2023-06-16-00
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

(1) Since this defines a behavior where one incoming packet can create N
outgoing packets, I was surprised that there is nothing mentioned in the
security considerations about how access to replication nodes and ingress for
them should be protected in order to prevent abuse.

(2) The intended use seems mainly to be where some outer control system is
responsible for making sure that the replication operation will put packets
onto distinct network paths, and not create congestion either locally or on
some potential shared network segment downstream.  It might be more clearly
stated that it's assumed that building a proper multicast tree, managing group
membership, and performing multicast congestion control need to be performed
elsewhere.

(3) I didn't recognize the syntax or pseudocode conventions in section 2.2.1;
maybe this is common or defined somewhere else that could be referenced to be
clear?