Hi Mirja,
please see inline:
On 15/12/17 16:50 , Mirja Kuehlewind (IETF) wrote:
Hi Peter,
please see below.
Am 14.12.2017 um 15:34 schrieb Peter Psenak <[email protected]>:
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
Thanks! Given these things are addressed in different doc, maybe it would make
sense to give a respective reference to these docs...?
this document specifies requirements without talking about any specific
solutions. I'm not sure if adding a references to a documents that
provide solutions for these would be appropriate. New solutions may
become available over time and we do not want the be limited to those
that exists today.
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.
No, what I meant was just to inform the source that provided the SR information
that the (pre-computer) local repair is in use instead of the originally
indicated route. Given the fact that SR routing uses source routing, I just
thought the source might want to know that the local repair was used instead.
But that was just a thought...
well, that may be problematic as many sources may be sending over the
same primary path.
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.
Not for ECMP but that was the first point in section 2 describes.
Liveness of each ECMP path can be independently monitored using mechanisms
described in draft-ietf-spring-oam-usecase.
Yes, what I was saying is more an editorial comment because the text only says
that monitoring is need for option 3 in section 2 (primary/backup) and does not
say anything about the need of monitoring for option 2 (ECMP) which is needed
as well as you also say above. Please double-check the text there!
I see. I suppose you are referring to the text that says:
"It is essential that the primary and backup path benefit from an end-
to-end liveness monitoring/verification."
I can change the text to say:
"It is essential that any path, primary or backup, benefit from an
end-to-end liveness monitoring/verification".
Would that be ok?
thanks,
Peter
Mirja
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
