> > 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.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
