Lars, Responses inline @ [RP] On Fri, Aug 4, 2023 at 1:26 AM Lars Eggert via Datatracker <nore...@ietf.org> wrote:
> Lars Eggert has entered the following ballot position for > draft-ietf-spring-sr-replication-segment-16: Discuss > > > ---------------------------------------------------------------------- > 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. > [RP] May I ask what you think is missing in the Security section text about loops? Additionally, this documents needs to specify suitable > countermeasures - it is not sufficient to leave this up to > unspecified control plane mechanisms. > [RP] This document is just specifying behavior of a single replication segment. The use of PCE as a controller to create a tree by stitching replication segments in specified in PIM WG document ( draft-ietf-pim-sr-p2mp-policy <https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/>) and PCEP protocol extensions are described in PCE WG doc ( draft-ietf-pce-sr-p2mp-policy <https://datatracker.ietf.org/doc/draft-ietf-pce-sr-p2mp-policy/>). > > > ---------------------------------------------------------------------- > 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. > [RP] This came up in WG discussion during WGLC about "sharing" a downstream replication segment across multiple "upstream" replication segments (possibly to enable Multipoint-to-Multipoint). Although this is feasible, it is only possible to do this when a complex set of conditions are satisfied. This adds complexity to both control plane and data plane (like needing "outer" and "inner" replication segment context in packets). Hence, it was kept out of scope of this document. > > ### 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? > [RP] This text was for any future extension (say one that defines a destination option) to mandate supporting exception 2). However, I agree the last sentence is not really necessary. I will remove it in the next revision.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
