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

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 14 Dec 2017 04:55:17 -0800

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?

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?

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.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 14 Dec 2017 15:34:13 +0100

Hi Mirja,

I took the editor role from Stefano.

Please see inline:

> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/

    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

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

> mentioned that this also needs more capacity and can therefore cause

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-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 15 Dec 2017 17:12:05 +0100

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-masked]>:
>>
>> Hi Mirja,
>>
>> 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.
>>
>>
>> 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.
>>
>>
> 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.

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

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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 15 Dec 2017 16:50:00 +0100

Hi Peter,

please see below.

Mirja