Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement
Hi All, I’m coming back to this old thread as I follow up on my AD review of the draft. My attention was caught by Samuel’s point that the SHOULD/MAY is justified by, "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.” If this is indeed the reason for the SHOULD/MAY, I think it’s desirable to make it as clear as possible in the spec, for example (added sentence) OLD: When both L flag and E flag are set to 0, then the PCE SHOULD consider the protection eligibility as an UNPROTECTED PREFERRED constraint but MAY consider protection eligibility as an UNPROTECTED MANDATORY constraint. NEW: When both L flag and E flag are set to 0, then the PCE SHOULD consider the protection eligibility as an UNPROTECTED PREFERRED constraint but MAY consider protection eligibility as an UNPROTECTED MANDATORY constraint. An example of when the latter behavior might be chosen is if the PCE has some means (outside the scope of this document) to detect that it’s interacting with a legacy PCC that expects the legacy behavior. I think some change like this would go a long way toward heading off further questions on this point during IETF Last Call and IESG review. Thanks, —John > On Jan 11, 2023, at 11:28 AM, Andrew Stone (Nokia) > wrote: > > > Hi Pavan, Dhruv, Samuel, > > Correct – that text is trying to steer implementors to use unprotected > preferred but is keeping the option of unprotected mandatory for backwards > compatibility.https://mailarchive.ietf.org/arch/msg/pce/4EX28antvCp_2CY--7RJmCvR-jo/ > discusses it a bit from a different angle (I assume the thread pointer > comment below is for this thread. > > Thanks > Andrew > > From: "Samuel Sidor (ssidor)" > Date: Wednesday, January 11, 2023 at 4:36 AM > To: Dhruv Dhody , Vishnu Pavan Beeram > , "Andrew Stone (Nokia)" > Cc: "pce@ietf.org" , > "draft-ietf-pce-local-protection-enforcem...@ietf.org" > > Subject: RE: [Pce] Question on draft-ietf-pce-local-protection-enforcement > > 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 On Behalf Of Dhruv Dhody > Sent: Wednesday, January 11, 2023 9:29 AM > To: Vishnu Pavan Beeram > Cc: pce@ietf.org > 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 > wrote: >> Dhruv, Hi! >> >> Thanks for the response! Please see inline.. >> >> Regards, >> -Pavan >> >> On Wed, Jan 11, 2023 at 12:03 PM Dhruv Dhody wrote: >>> Hi Pavan, >>> >>> On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram >>> 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 >>
Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement
Hi Pavan, Dhruv, Samuel, Correct – that text is trying to steer implementors to use unprotected preferred but is keeping the option of unprotected mandatory for backwards compatibility. https://mailarchive.ietf.org/arch/msg/pce/4EX28antvCp_2CY--7RJmCvR-jo/ discusses it a bit from a different angle (I assume the thread pointer comment below is for this thread. Thanks Andrew From: "Samuel Sidor (ssidor)" Date: Wednesday, January 11, 2023 at 4:36 AM To: Dhruv Dhody , Vishnu Pavan Beeram , "Andrew Stone (Nokia)" Cc: "pce@ietf.org" , "draft-ietf-pce-local-protection-enforcem...@ietf.org" Subject: RE: [Pce] Question on draft-ietf-pce-local-protection-enforcement 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 On Behalf Of Dhruv Dhody Sent: Wednesday, January 11, 2023 9:29 AM To: Vishnu Pavan Beeram Cc: pce@ietf.org 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 mailto:vishnupa...@gmail.com>> wrote: Dhruv, Hi! Thanks for the response! Please see inline.. Regards, -Pavan On Wed, Jan 11, 2023 at 12:03 PM Dhruv Dhody mailto:dhruv.i...@gmail.com>> wrote: Hi Pavan, On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram mailto:vishnupa...@gmail.com>> 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
Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement
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 On Behalf Of Dhruv Dhody Sent: Wednesday, January 11, 2023 9:29 AM To: Vishnu Pavan Beeram Cc: pce@ietf.org 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 mailto:vishnupa...@gmail.com>> wrote: Dhruv, Hi! Thanks for the response! Please see inline.. Regards, -Pavan On Wed, Jan 11, 2023 at 12:03 PM Dhruv Dhody mailto:dhruv.i...@gmail.com>> wrote: Hi Pavan, On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram mailto:vishnupa...@gmail.com>> 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 Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement
Hi Pavan, On Wed, Jan 11, 2023 at 12:46 PM Vishnu Pavan Beeram wrote: > Dhruv, Hi! > > Thanks for the response! Please see inline.. > > Regards, > -Pavan > > On Wed, Jan 11, 2023 at 12:03 PM Dhruv Dhody wrote: > >> Hi Pavan, >> >> On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram < >> vishnupa...@gmail.com> 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 >>> Pce@ietf.org >>> https://www.ietf.org/mailman/listinfo/pce >>> >> ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement
Dhruv, Hi! Thanks for the response! Please see inline.. Regards, -Pavan On Wed, Jan 11, 2023 at 12:03 PM Dhruv Dhody wrote: > Hi Pavan, > > On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram < > vishnupa...@gmail.com> 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? > > Happy to get additional eyes and confirm if it still makes sense! > > Thanks! > Dhruv > > > >> Regards, >> -Pavan >> ___ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement
Hi Pavan, On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram 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. 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. Happy to get additional eyes and confirm if it still makes sense! Thanks! Dhruv > Regards, > -Pavan > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Question on draft-ietf-pce-local-protection-enforcement
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)? Regards, -Pavan ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
