Lars, My point is this draft specifies behavior of a single replication segment which can be deployed for ingress replication like service (similar to End.DT2M for Layer 2 BUM) without needing a control plane - either by local provisioning on root and leaf nodes or by using overlay automatic discovery mechanisms like BGP MVPN procedures. Loops don't arise in this case unless underlying unicast point-to-point paths between a Root and Leaf nodes have loops, but this is out of scope of this document.
Loops can only arise when replication segments are stitched together to form a P2MP tree. Typically, this requires a control plane; draft-ietf-pim-sr-policy is specification of one such control plane (using PCE as centralized P2MP compute). I think it is appropriate to document loop prevention or mitigation there. But it is not necessary to use a control plane to deploy a single replication segment. Hence I don't think this document needs to have a normative reference to the PIM WG draft. >> [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. >Those other documents should then update this one, allowing this option and describing the details. This is precisely why sharing of replication segment is out of scope of this document. Thanks, -Rishabh On Wed, Aug 23, 2023 at 2:59 AM Lars Eggert <l...@eggert.org> wrote: > Hi, > > On Aug 11, 2023, at 21:40, Rishabh Parekh <risha...@gmail.com> wrote: > > 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. > > I'm missing a normative reference to at least one control plane that > satisfies this requirement. > > > 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. > > Safe deployment of this technology requires that loop congestion collapse > be prevented. If the only way to achieve this is by requiring a control > plane, that must be a normative reference. If there is some other way to > prevent loop congestion without a control plane, this document or a > normative reference must specify how this is done. > > > > 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. > > If draft-ietf-pim-sr-p2mp-policy is the control plane that contains the > loop congestion collapse protection, it must also become a normative > reference. > > > > ### 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. > > Those other documents should then update this one, allowing this option > and describing the details. > > Thanks, > Lars > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
