Re: [spring] [Last-Call] Tsvart last call review of draft-ietf-spring-sr-replication-segment-14

[Joel Halpern <[e-mail]>]

I will leave it to the authors and shepherd to respond, including 
whether to add a reference for the pseudo-code in 2.2.1.

Just to save one piece of effort, the pseudo-code technique used here 
was introduced in RFC 8986, and is used in almost all the SRv6 related 
drafts / RFCs.  While I am not a fan of the particular formalism, it is 
what SRv6 uses, and so we all live with it.

Yours,

Joel

On 6/16/2023 4:32 PM, Wesley Eddy via Datatracker wrote:
> Reviewer: Wesley Eddy
> Review result: Almost Ready
>
> 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
> [e-mail] 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?
>
>