Hi Aijun, Replies inline below with <Andrew>
Thanks Andrew On 2022-06-09, 11:32 PM, "Pce on behalf of Aijun Wang" <[email protected] on behalf of [email protected]> wrote: 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? <Andrew> The intent is to actually make path and SID selection behavior more consistent between PCE's, as right now the existing language is vague to the nature of a link with multiple sids which may or may not support protection, and interop tests have exposed differences of interpretation and thus implementation, so I would argue things are already difficult from an interoperability point of view while this document clarifies that. In addition, the additional definitions are solving TE requirements such as UNPROTECTED_MANDATORY, which I'll comment on more further below (which indeed are customer situations). UNPROTECTED PREFERRED is a guidance on how PCE should interpret when L bit is not set and is being backwards compatible with existing known implementations prior to this document. 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. <Andrew> If the document declares only L bit means PROTECTED MANDATORY, then the capability to do UNPROTECTED MANDATORY cannot be achieved. Aside from that, when L bit is not set, without this document then PCE implementation have no guidance on which SID should be selected in the scenario a link has multiple SIDs (one backup supported, one not) leading to interoperable differences on the same network which may have multiple vendors deployed. as per section 4 in the document, both compatibility and new requirements are coupled and being addressed by the document. Regarding the use case for UNPROTECTED MANDATORY, one scenario which sparked this involved a provider offering different levels of service, capacity and guarantees to their end customers on a network with very explicit TE requirements and expected TE behavior. For one type of service, disjoint TE paths would be established. The operator did not want any interim re-routing of traffic flow off of the defined TE path as the volume of that data being carried would negatively impact the links in which it may be temporarily traversing via LFA. In addition, due to the network design and diversity design, re-routing of the impacted path was either undesired (from a network management point of view) OR not feasible (no alternative path that’s also disjoint), so the traffic would stay in LFA until the path was brought down intentionally by PCE, before switching to the protected path anyways. The key thing is for this service, temporary fast rerouting on a non TE managed path was not wanted. In another service type, fast re-route protection was offered but without a diverse backup path. Essentially different levels of service had different TE and SLA requirements operating on the same network. Recently, draft-schmutzer-pce-cs-sr-policy has formalized the concept of Circuit Style Segment Routing Policies, which also has a need for UNPROTECTED MANDATORY (see section 5). Aijun Wang China Telecom > On Jun 7, 2022, at 17:19, [email protected] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
