Hi Eric,
I took the editor role from Stefano.
Please see inline:
On 13/12/17 01:45 , Eric Rescorla wrote:
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
fixed.
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"
fixed.
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.
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.
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?
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".
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?
not really. These are two alternatives of "local protection", in
contrast to the "path protection" described in section 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.
no, you are not misreading - "demand" is not the right word. I changed
to "traffic".
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"
fixed.
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?
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.
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"
fixed
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"
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 protected]
https://www.ietf.org/mailman/listinfo/spring
.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
