Hi Pavan,
On Wed, Jan 11, 2023 at 12:46 PM Vishnu Pavan Beeram <[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]> wrote: > >> Hi Pavan, >> >> On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram < >> [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] >>> https://www.ietf.org/mailman/listinfo/pce >>> >>
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
