Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks
RFC 8355
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
Alvaro Retana Yes
(Alia Atlas; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
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..."?
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
- 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..."
(Benoît Claise; former steering group member) No Objection
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.
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
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"
(Kathleen Moriarty; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
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.
(Spencer Dawkins; former steering group member) No Objection
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.
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection