Hi Dhruv, Vishnu, “I think we can differentiate between an implementation that supports this extension - that MUST use UNPROTECTED PREFERRED whereas a legacy implementation would handle it as per their understanding of RFC 5440 which could be UNPROTECTED PREFERRED or UNPROTECTED MANDATORY.”
Wouldn’t such change break backward compatibility? Consider that there is vendor, with original behavior L=0 -> unprotected mandatory (on both PCC and PCE side) – as Dhruv mentioned, such implementation would be completely valid with original L flag definition. Same old PCC will connect to new PCE (with draft supported) and suddenly (unexpected) different path-computation result is provided, because behavior has changed. PCE can still have a way to detect that it is talking to legacy PCCs and it can fallback to original behavior to do not break backward compatibility. I’ll keep Andrew to comment as he is main author. Regards, Samuel From: Pce <[email protected]> On Behalf Of Dhruv Dhody Sent: Wednesday, January 11, 2023 9:29 AM To: Vishnu Pavan Beeram <[email protected]> Cc: [email protected] Subject: Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement Hi Pavan, On Wed, Jan 11, 2023 at 12:46 PM Vishnu Pavan Beeram <[email protected]<mailto:[email protected]>> wrote: Dhruv, Hi! Thanks for the response! Please see inline.. Regards, -Pavan On Wed, Jan 11, 2023 at 12:03 PM Dhruv Dhody <[email protected]<mailto:[email protected]>> wrote: Hi Pavan, On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram <[email protected]<mailto:[email protected]>> wrote: I would like to get some clarification on the text below (understand that a publication request has been made for the draft). ** From Section 5: When L-flag is not set and E-flag is not set then PCE SHOULD consider the protection eligibility as UNPROTECTED PREFERRED but MAY consider protection eligibility as UNPROTECTED MANDATORY constraint. When L-flag is not set and E-flag is set then PCE MUST consider the protection eligibility as UNPROTECTED MANDATORY constraint. ** For the scenario where both the L-flag and the E-flag are not set (first statement above), it seems okay to just say that the "PCE MUST consider the protection eligibility as UNPROTECTED PREFERRED". Is there a good reason for both the "SHOULD (UNPROTECTED PREFERRED)" and "MAY (UNPROTECTED MANDATORY)" clauses to be included here (and keep things ambiguous)? Dhruv: If I recall correctly (and the authors can confirm that), this was done for the sake of backward compatibility. I remember it being discussed on the mailing list as well. [VPB] Thanks for the pointer to the mailing list thread (should have searched there first; apologies for re-opening the topic) -- it was useful! However, the backwards compatibility section (5.1) seems to be silent about this particular scenario. If a PCEP speaker does not understand this document (and thus ignores the E flag) and L flag is set to 0, would behave as per RFC 5440 where the concept of enforcement is undefined and some implementation could understand it to be handled as UNPROTECTED MANDATORY instead of UNPROTECTED PREFERRED. And the text allows for it. [VPB] I understand that there was ambiguity with how the (presence/absence of the) L-flag was interpreted prior to this draft. I was hoping that there would be no ambiguity left when this draft is implemented -- but that doesn't seem to be the case. Let's say a PCC implementation assumes [L 0, E 0] to mean "UNPROTECTED PREFERRED" (SHOULD clause), while the PCE implementation assumes it to mean "UNPROTECTED MANDATORY" (MAY clause) -- this may result in no path being returned (if only protected SIDs are available on some links along the viable paths). Do we need to retain this ambiguity? Dhruv: You have a point. I think we can differentiate between an implementation that supports this extension - that MUST use UNPROTECTED PREFERRED whereas a legacy implementation would handle it as per their understanding of RFC 5440 which could be UNPROTECTED PREFERRED or UNPROTECTED MANDATORY. Let's see what the authors think about it. Thanks! Dhruv Happy to get additional eyes and confirm if it still makes sense! Thanks! Dhruv Regards, -Pavan _______________________________________________ Pce mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
