Re: [spring] Mirja Kühlewind's No Objection on draft-ietf-spring-resiliency-use-cases-11: (with COMMENT)

Hi Peter,

please see below.

> Am 14.12.2017 um 15:34 schrieb Peter Psenak <ppsenak@cisco.com>:
> 
> 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
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>> 
> 