Hi, All: After reading this draft, my feel is that it make the situation more complex. Won’t it be more difficult for interoperability from different vendors, or from the different versions of the same vendor? And, is there any situation that the customer want “UNPROTECTED MANDATORY” service? or “UNPROTECTED PREFERRED” service?
How about just clarify the usages of “L” bit in RFC5440, for example: when this flag is set, it mean “PROTECTED MANDATORY”, or else, if it is unset, then it depends on the transit router’s capabilities?( I am struggle to image which kind of customers will declare explicitly that they don’t want protection if the service providers does not charge more for the possible protection action) And, if possible, can authors explain in more detail why the customer has the following requirements: “For another example, UNPROTECTED MANDATORY is when an operator may intentionally prefer an LSP to not be locally protected, and thus would rather local failures to cause the LSP to go down and/or rely on other protection mechanisms such as a secondary diverse path.” Clarifying the necessary of different requirements is the base for the extension of protocol. Aijun Wang China Telecom > On Jun 7, 2022, at 17:19, julien.meu...@orange.com wrote: > Dear all, > > This message starts a 2-week Working Group Last Call > fordraft-ietf-pce-local-protection-enforcement-05 [1]. > > Please share your comments using the PCE mailing list. Any levels of reviews > are very welcome and all feedback remain useful to check the readiness of the > document. > > This LC will end on Wednesday June 22, 2022. > > Thanks, > > Dhruv & Julien > > > [1] > https://datatracker.ietf.org/doc/html/draft-ietf-pce-local-protection-enforcement > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
