Subject: [spring] Eric Rescorla's No Objection on draft-ietf-spring-resiliency-use-cases-11: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Dec 2017 16:45:07 -0800

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"

---

From: Peter Psenak <[email-masked]>
Date: Thu, 14 Dec 2017 14:34:40 +0100

Hi Eric,

I took the editor role from Stefano.

Please see inline:

> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/

fixed.

> "consists of" and "instead uses"

fixed.

> additional requirement that isn't provided by the topology given.

it is meant to say that it fulfills that requirement.

I changed to wording to:

"The two paths MUST be disjoint in their links, nodes and shared risk 
link groups (SRLGs) to satisfy the requirement of disjointness.'

Hopefully that makes it clear.

> otherwise be protected? Are you computing paths in such a way that they will

what is important is the "local repair techniques". The requirement is 
that the path is not locally protected by Fast Reroute techniques, but 
is protected as a end-to-end path. I would tend to replace the "MUST
NOT" with "are not".

> These are alternative strategies to the one described in S 2?

not really. These are two alternatives of "local protection", in 
contrast to the "path protection" described in section 2.

> "demand"? I would have assumed you meant "packet" or "datagram" here, but maybe

no, you are not misreading - "demand" is not the right word. I changed 
to "traffic".

>     path comes back up, the operator either allows for an automated

fixed.

> Why would you want the mechanism in S 3.1 rather than S 3.2?

the difference between 3.1 and 3.2 is that in 3.1 you are bypassing the 
protected resource (e.g. link) and force the traffic back to the 
original path. In 3.2, you send the traffic over the shortest path to 
the destination from the point of local repair. Why would you want the 
3.1. behavior? One reason to keep the traffic on the original path as 
much as possible is to avoid overloading some of the links which would 
have to take additional traffic during protection time.

>     microloops-avoidance techniques may be applied.  An example of such

fixed
>     enabled router could take advantage of the increased packet steering

fixed.

I will post the new revision once we close on all open items from you 
and other reviewers.

thanks,
Peter

>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
> .
>