Skip to main content

Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks
draft-ietf-spring-resiliency-use-cases-12

Yes

(Alia Atlas)
(Alvaro Retana)

No Objection

(Alexey Melnikov)
(Alissa Cooper)
(Deborah Brungard)
(Kathleen Moriarty)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 11 and is now closed.

Alia Atlas Former IESG member
Yes
Yes (for -11) Unknown

                            
Alvaro Retana Former IESG member
Yes
Yes (for -11) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (2017-12-13 for -11) Unknown
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 IESG member
No Objection
No Objection (for -11) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2017-12-13 for -11) Unknown
- 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 IESG member
No Objection
No Objection (2017-12-13 for -11) Unknown
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 IESG member
No Objection
No Objection (for -11) Unknown

                            
Eric Rescorla Former IESG member
No Objection
No Objection (2017-12-12 for -11) Unknown
   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 IESG member
No Objection
No Objection (for -11) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2017-12-14 for -11) Unknown
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 IESG member
No Objection
No Objection (2017-12-13 for -11) Unknown
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 IESG member
No Objection
No Objection (for -11) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -11) Unknown