Eric Rescorla has entered the following ballot position for draft-ietf-spring-resiliency-use-cases-11: No Objection
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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As a reminder, one of the majors network operator requirements is path disjointness capability. Network operators have deployed Nit: major A first protection strategy consists in excluding any local repair but instead use end-to-end path protection where each SPRING path is protected by a second disjoint SPRING path. In this case local Nits: "consists of" and "instead uses" path. As a requirement, the two paths MUST be disjoint in their links, nodes or shared risk link groups (SRLGs). Do you mean to say that this fulfills that requirement? Or is this an additional requirement that isn't provided by the topology given. o SPRING architecture MUST provide a way to compute paths that MUST NOT be protected by local repair techniques (as illustrated in the example of paths T1 and T2). This MUST NOT is kind of unclear. Are you computing paths that will not otherwise be protected? Are you computing paths in such a way that they will not be protected? This section describes two alternatives providing local protection without requiring operator management, namely bypass protection and These are alternative strategies to the one described in S 2? For example, a demand from A to Z, transported over the shortest paths provided by the SPRING architecture, benefits from management- "demand"? I would have assumed you meant "packet" or "datagram" here, but maybe I am misreading. destination Z. Upon local detection of the failure, the traffic is repaired over the backup path in sub-50 milliseconds. When primary path comes back up, the operator either allows for an automated Nit: "When the primary" an automated reversion of the traffic onto the primary path or selects an operator-driven reversion. Why would you want the mechanism in S 3.1 rather than S 3.2? of their topologies. Detecting microloops can be done during topology computation (e.g.: SPF computation) and therefore microloops-avoidance techniques may be applied. An example of such Nit: "e.g., SPF" network state. Traditionally, the lack of packet steering capability made difficult to apply efficient solutions to microloops. A SPRING enabled router could take advantage of the increased packet steering Nit: "made it difficult" _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
