Hi Aijun, Thanks for the feedback. I'll make the below additions to the document and upload later this week, to allow for any other feedback/changes to come in.
Thanks Andrew ---------------- Section 4.2 ---------------- BEFORE The selection of the options are typically dependent on the service level agreement the operator wishes to impose on the LSP. AFTER The selection for one of the options is typically dependent on the service level agreement the operator wishes to impose on the LSP. A network may be providing transit to multiple service agreement definitions against the same base topology network, whose behavior could vary, such as wanting local protection to be invoked on some LSPs and not wanting local protection on others. ---------------- Section 4.2 ---------------- BEFORE 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. AFTER 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. An example scenario is one where an LSP is protected with path protection via a secondary diverse LSP. Each LSP is traffic engineered to follow specific traffic engineered criteria computed by PCE to satisfy SLA. Upon a failure, if local protection is invoked on the active LSP traffic, the traffic may temporarily traverse links which violate the TE requirements and could negatively impact the resources being traversed (ex: insufficient bandwidth). In addition, depending on the network topological scenario, it may be not feasible for PCE to reroute the LSP while respecting the TE requirements which include path diversity, resulting for the LSP to be torn down and switched to the protected path anyways. In such scenarios its desirable for the LSP to be simply torn down immediately and not re-routed through local protection mechanisms, so that traffic may be forwarded through an already established traffic engineered secondary path. ---------------- Section 5 ---------------- BEFORE UNPROTECTED PREFERRED and PROTECTED PREFERRED may seem similar but they indicate the preference of selection of a SID if PCE has an option of either protected or unprotected available on a link. AFTER UNPROTECTED PREFERRED and PROTECTED PREFERRED may seem similar but they indicate the preference of selection of a SID if PCE has an option of either protected or unprotected available on a link. The definition of UNPROTECTED PREFERRED Is primarily as a guidance on how PCE should interpret and behave when L bit is not set, maintaining compatibility with existing known implementations prior to this document. On 2022-06-12, 9:16 PM, "Aijun Wang" <[email protected]> wrote: Hi, Andrew: Thanks for your explanation. I think adding these descriptions into the document would be helpful to the reader to know the necessary of the protocol extension. I support its forwarding. Aijun Wang China Telecom > On Jun 10, 2022, at 23:20, Stone, Andrew (Nokia - CA/Ottawa) <[email protected]> wrote: > > 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
