Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

[Alexander Vainshtein <[e-mail]>]

Rob,
Lots of thanks for a prompt response.

Two comments:

1.       I fully agree with you that use cases drafts should not be exhaustive. But from my POV they should not be prohibitive (or be interpreted as prohibitive) either, exactly because “Operators can, and will continue to, deploy things that (shockingly!) are not described in IETF use case documents”.

2.       I have looped up the definition of B-flag in the IS-IS Extensions for SR<https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/?include_text=1> draft, and it looks confusing to me:

a.       This flag is used with Adj-SIDs and, if it is set, the corresponding adjacency is “eligible for protection (e.g.: using IPFRR or MPLS-FRR) as described in  [I-D.ietf-spring-resiliency-use-cases]”

b.      Unfortunately. the Resiliency Use Cases<https://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-10> draft does not mention IPFRR, MPLS-FRR or the term “eligible” at all.  So the expected behavior associated with this flag (and, specifically, its relation with suppression of local protection) are not clear to me.
What did I miss?

Regards, and lots of thanks in advance,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Rob Shakir [mailto:[e-mail]]
Sent: Tuesday, May 16, 2017 6:32 PM
To: Alexander Vainshtein <[e-mail]>; Stefano Previdi (sprevidi) <[e-mail]>
Cc: [e-mail]; Shell Nakash <[e-mail]>; Michael Gorokhovsky <[e-mail]>; [e-mail]; Sidd Aanand <[e-mail]>; Ron Sdayoor <[e-mail]>; Rotem Cohen <[e-mail]>; Stephane Litkowski <[e-mail]>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

As long as "mixed" use cases are not strictly prohibited in the draft (and this was at least one possible interpretation of the text), I do not have any issues with restricting it to just two "pure" use cases:
- End-to-end path protection with disabled local protection
- Local protection (of some kind) without end-to-end path protection.

Use cases drafts should never attempt to be exhaustive in terms of what they try and cover, but provide sufficient motivation for the features that are/were required in the technology that is developed as a response to them. In this case, the use case of path protection - especially with disjointness requirements - provides motivation for wanting to have a SID in the network that is explicitly not protected by local protection mechanisms.

In RSVP-TE, we have the ability to set the "local protection requested" bit described in RFC4090 - which gives the head-end the ability to control the re-route behaviour of the LSP. This use case presents the operational case for the B-flag in the IGP extensions.

Operators can, and will continue to, deploy things that (shockingly!) are not described in IETF use case documents. At this point, if we consider that this document provides some explanation of the features that are required in the protocol - let's go ahead and publish it. Due to the different technical and business requirements of different operators, almost certainly, someone will deploy some combination of these features, but I do not feel that we need to describe such unknown cases within this document.

Kind regards,
r.

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________