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

[Rob Shakir <[e-mail]>]

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