Lars Eggert has entered the following ballot position for draft-ietf-spring-sr-replication-segment-16: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # GEN AD review of draft-ietf-spring-sr-replication-segment-16 CC @larseggert Thanks to Thomas Fossati for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/WF6_i6kgEP9J8_frlekZtnm_6sQ). ## Discuss ### Paragraph 0 This document introduces packet replication functionality into SR networks. This significantly increases and complicates the attack surface of the technology while at the same time introducing severe new misconfiguration possibilities (e.g., multicast amplification loops that can lead to congestion collapse of the network.) This document does not adequately describe and discuss these issues. Additionally, this documents needs to specify suitable countermeasures - it is not sufficient to leave this up to unspecified control plane mechanisms. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Comments ### Section 2, paragraph 18 ``` In principle it is possible for different Replication segments to replicate packets to the same Replication segment on a Downstream node. However, such usage is intentionally left out of scope of this document. ``` What was the intent of leaving this out? There seems to be complexity here that can be abused, in which case I would have expected this to either be explicitly forbidden or discussed in sufficient detail to understand (and mitigate) the issues. ### Section 2.2.3, paragraph 2 ``` An implementation of Replication segment for SRv6 MUST enforce these same restrictions and exceptions. Though this specification does not use any extension header a future extension may do so and MUST support the exception (2) above. ``` It is unusual for a spec to limit what a future extension can do in this way (and often it turns out to be too limiting) - why is this content needed in this document? ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Section 2, paragraph 18 ``` an indicator role of the node is Leaf. The operation performed on incoming Replication SID is NEXT https://www.rfc-editor.org/rfc/ rfc8402#section-2. At an egress node, the Replication SID MAY be ``` Document uses `eref` elements that convert into plaintext URLs in the document (above and elsewhere), which make things difficult to read. Convert to proper references? ### Grammar/style #### Section 1.1, paragraph 5 ``` des the ingress (Root) node of a multi-point service and the egress (Leaf) no ^^^^^^^^^^^ ``` This word is normally spelled as one. (Also elsewhere.) #### Section 2.1, paragraph 8 ``` ote that this H.Encaps.Red is independent from the replication segment – it i ^^^^^^^^^^^^^^^^ ``` The usual collocation for "independent" is "of", not "from". Did you mean "independent of"? #### Section 2.2, paragraph 7 ``` is variant of End behavior. The pseudo-code in this section follows the conv ^^^^^^^^^^^ ``` This word is normally spelled as one. (Also elsewhere.) #### Section 2.2.3, paragraph 1 ``` this draft does not specify any inter-operable elements of Replication segme ^^^^^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 8.2, paragraph 4 ``` 6, using N-SID6, steers packet via shortest path to that node. Replication to ^^^^^^^^ ``` A determiner may be missing. #### "A.1.", paragraph 11 ``` b8:cccc:6:F6::0, steers packet via shortest path to that node. Replication to ^^^^^^^^ ``` A determiner may be missing. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
