Hi Mirja,
I took the editor role from Stefano.
Please see inline:
On 14/12/17 13:55 , Mirja Kühlewind wrote:
Mirja Kühlewind 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:
----------------------------------------------------------------------
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?
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).
one way of achieving this is to construct the path using the
non-protected Adj-SIDs as specified in 3.4. of
draft-ietf-spring-segment-routing-13.txt.
o SPRING architecture MUST provide a way to instantiate pairs of
disjoint paths on a topology based on a protection strategy (link,
node or SRLG protection) and allow the validation or re-
computation of these paths upon network events.
there are multiple ways how disjoint paths can be provided - one is the
usage of the internal or external PCE engine, which computed and encodes
the disjoint paths as a set of SR segments. An alternative way is
described in draft-hegdeppsenak-isis-sr-flex-algo.
o The SPRING architecture MUST provide end-to-end liveness check of
SPRING based paths.
described in draft-ietf-spring-oam-usecase
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?
I'm not sure I really understand what you are asking. Section 3 talks
about the local repair mechanisms that pre-program the alternative paths
before the failure and traffic uses them once the failure is
encountered. I'm not sure why the traffic would not take it when the
failure happens and why a reporting mechanism is required.
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.
there is no intention to send same packet over multiple ECMP paths as
that would be doubling the traffic. Liveness of each ECMP path can be
independently monitored using mechanisms described in
draft-ietf-spring-oam-usecase.
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
