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...? > > >> >> 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... > >> >> 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! 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
