Summary: Has enough positions to pass.
- Requirements Language: The 2119 keywords in this draft are not used in the sense of RFC 2119. That RFC talks explicitly about interoperability among protocol implementations. This draft uses them to define requirement for protocol and architecture design. That's not necessarily a problem, but please change the Requirements Language section to describe the actual usage. -2, third paragraph from end: "o SPRING architecture MUST provide a way to compute paths that MUST NOT be protected by local repair techniques..." The MUST NOT seems a statement of fact. Consider something to the effect of "... compute paths that are not protected by local repair techniques..."
Some redundancy in the intro first two paragraphs.: This document reviews various use cases for the protection of services in a SPRING network. The terminology used hereafter is in line with [RFC5286] and [RFC5714]. This document reviews various use cases for the protection of services in a SPRING network.
I agree with Ben's point about RFC 2119/8174 requirements keyword usage. For example, I'm looking at the MUST NOT in 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 protection MUST NOT be used. and wondering why that's normative. I would have guessed that the point was, "if you use local protection, you're not carrying out the end-to-end path protection strategy that this section describes", but that isn't an RFC 2119/8174 interoperation keyword thing. What am I missing here? I agree with Adam's confusion about Usually, in a normal routing protocol operations, microloops do not last long enough and in general they are noticed during the time it takes for the network to converge. I assumed that this was supposed to say something like Usually, in a normal routing protocol operations, microloops do not last long enough to be noticed during the time it takes for the network to converge. but the current text isn't clear.
I have a question which is probably simply the result of not having had time to read all spring docs in detail: Can you maybe indicate how the requirements at the end of section 2 have been addressed in the spring architecture doc? And another question on section 3: Wouldn't it also make sense to have a mechanism that reports if local repair was used and respectively the traffic was not routed over the indicated path but a different one? And another comment on section 2: You write that you need a way to check the liveness of a path if used for primary and backup, however, this is also true for the case where the two paths are used with ECMP as it usually doesn't help you that much if you only receive half of your packets. Only if you send all packets over both paths, you don't need a active check, however, it should be mentioned that this also needs more capacity and can therefore cause unnecessary congestion.
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"
I *think* I found a minor issue. Section 5 contains the following text: Usually, in a normal routing protocol operations, microloops do not last long enough and in general they are noticed during the time it takes for the network to converge. I'm assuming this is intended to say "...are not noticed..."?