[spring] Tsvart last call review of draft-ietf-spring-sr-replication-segment-14
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 tsv-...@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? ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] [Last-Call] Tsvart last call review of draft-ietf-spring-sr-replication-segment-14
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 tsv-...@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? ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Tsvart last call review of draft-ietf-spring-sr-replication-segment-14
Wesley, Thanks for the review. The Replication function is performed by nodes within an SR domain. The trust model of SR with traffic filtering at SR domain boundaries applies to this document and is covered by the first sentence referring to security considerations of RFCs 8402, 8986 and 8754. I will add some text addressing comment (2). As Joel mentioned, pseudo-code uses a convention introduced in SRv6 RFC 8986. I will add a reference to 8986 in Section 2.2.1. -Rishabh On Fri, Jun 16, 2023 at 1:33 PM Wesley Eddy via Datatracker < nore...@ietf.org> 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 > tsv-...@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? > > > ___ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
