Lars, Revision 17 addresses your concerns about loop prevention and other comments.
Please take a look, -Rishabh On Fri, Aug 11, 2023 at 11:40 AM Rishabh Parekh <risha...@gmail.com> wrote: > Lars, > Inline @ [RP2] > > Thanks, > -Rishabh > > On Thu, Aug 10, 2023 at 12:54 AM Lars Eggert <l...@eggert.org> wrote: > >> Hi, >> >> On Aug 10, 2023, at 00:24, Rishabh Parekh <risha...@gmail.com> wrote: >> > 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? >> >> A way to detect and/or mitigate the effects of loop congestion. Or if >> that cannot be done in this document, a requirement that this technology >> MUST NOT be deployed without a control plane that either prevents loops or >> detects and mitigates their effects, and a normative reference to those >> control plane specs. >> > > [RP2] I will add a MUST requirement for a control plane to prevent or > detect/mitigate loops in steady state in the next revision. Local > provisioning of replication segments on SR nodes is valid too - maybe we > can add a SHOULD clause to prevent loops via local provisioning. However, I > don't think a normative reference to the control plane is required because > the behavior of a single replication segment - as specified in this > document does not necessitate a control plane. > > >> >> > 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) and PCEP protocol extensions are described >> in PCE WG doc (draft-ietf-pce-sr-p2mp-policy). >> >> draft-ietf-pim-sr-p2mp-policy is only cited informally, and >> draft-ietf-pce-sr-p2mp-policy not at all. If they do contain these >> countermeasures, they need to be cited normatively and their use needs to >> be required. However, I just skimmed them and neither seems to discuss >> loops or congestion? >> > > [RP] draft-ietf-pim-sr-p2mp-policy is really an "architecture" draft for > using PCE as a control plane for creating a tree by stichting replication > segments; draft-ietf-pce-sr-p2mp-policy is just PCEP signalling extensions > and hence not really referenced in this draft. Once we add the MUST > requirements in this draft, I will update draft-ietf-pim-sr-p2mp-policy to > satisfy this requirement. > >> >> > ### 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. >> >> So what you write seems to argue that this should then be explicitly >> forbidden? >> > > [RP2] No, it should not be forbidden, but left to other future documents > that can address the MP2MP use-case or replication segment sharing, if > required. > > >> >> Thanks, >> Lars >> >> >>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
