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
