Hi Marina, Can you please clarify more about “S-BFD resources have already finished”. Do you mean that PCC/headend can support limited number of BFD sessions and limit was already hit (so OOR)?
Anyway - good that we have more use cases for that change, so I’m personally fine with creating separate draft (split from draft-sidor-pce-binding-label-sid-extensions<https://datatracker.ietf.org/doc/draft-sidor-pce-binding-label-sid-extensions>), which will introduce generic definition of that D flag or some new capability TLV with bitmask, which will indicate whether peer can support creation of PCEInit LSP in case of various failures. We can still present that idea in next IETF as well since WG feedback in this mail thread seems to be limited. At least to see if WG prefers to have multiple bits or just single flag and whether there are use cases. Regards, Samuel From: Marina Fizgeer <marina.fizg...@rbbn.com> Date: Sunday, 24 August 2025 at 15:00 To: Marina Fizgeer <Marina.Fizgeer=40rbbn....@dmarc.ietf.org>, Samuel Sidor (ssidor) <ssi...@cisco.com>, Andrew Stone (Nokia) <andrew.stone=40nokia....@dmarc.ietf.org> Cc: pce@ietf.org <pce@ietf.org> Subject: RE: PCE WG Minutes for IETF 123 Hi, all, We have found another use case for the establishment of an LSP in a down state - for example, if a PCE-initiated LSP is defined with S-BFD, but S-BFD resources have already finished in the PCC. Such an LSP can be in a down state until S-BFD resources are freed (another LSP will be deleted, or S-BFD will be removed from some LSP, as an example). That is, today we already see 3 cases where the 'D' flag can be useful: If flag D is 1: bit#0 - if specified binding value is unavailable bit#1 – if specified path (ERO list) is not passed resolution bit#2 – S-BFD leak of resources What do you think? I would like to discuss this at the next IETF meetings; for this, we need to come to a common opinion. Also, where is it better to place this - in which draft? Best regards, [Logo]<https://ribboncommunications.com/> Marina Fizgeer Sr. Manager, Systems Architecture | Ribbon M +972.544860016 Petah Tikva, Israel [Banner]<https://ribboncommunications.com/?_gl=1*6qlbuc*_gcl_au*MjA3NzE5OTk5NC4xNzI4NDE0NDY4*_ga*NTIxNzg1MDgxLjE3Mjg0MTQ0NjM.*_ga_VCEZ9Q3S3Y*MTcyODQ1MjEzMC4yLjEuMTcyODQ1MjE4OS4xLjAuMTA4NjExNTU4> From: Marina Fizgeer <Marina.Fizgeer=40rbbn....@dmarc.ietf.org> Sent: Monday, August 11, 2025 10:30 AM To: Samuel Sidor (ssidor) <ssi...@cisco.com>; Andrew Stone (Nokia) <andrew.stone=40nokia....@dmarc.ietf.org> Cc: pce@ietf.org Subject: [EXTERNAL] [Pce] Re: PCE WG Minutes for IETF 123 Hi, Samuel and all, On the one hand, I agree with you that for certain use cases, a single flag may be sufficient. On the other hand, an additional 'bit string' or something like that gives us the ability to address each case separately, as well as to add new use cases in the future if they arise. And this can be, for example - your new draft and new checks. In addition, the presence of a bit string can guarantee that it will not be used for irrelevant cases where validation failure cannot be resolved. Regarding which draft - existing or new, I think it would be good to have a general new document for PCEP PCE initiated LSP new information (it's not the name, but sense only). Best regards, [Logo]<https://ribboncommunications.com/> Marina Fizgeer Sr. Manager, Systems Architecture | Ribbon M +972.544860016 Petah Tikva, Israel [Banner]<https://ribboncommunications.com/?_gl=1*6qlbuc*_gcl_au*MjA3NzE5OTk5NC4xNzI4NDE0NDY4*_ga*NTIxNzg1MDgxLjE3Mjg0MTQ0NjM.*_ga_VCEZ9Q3S3Y*MTcyODQ1MjEzMC4yLjEuMTcyODQ1MjE4OS4xLjAuMTA4NjExNTU4> From: Samuel Sidor (ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>> Sent: Wednesday, August 6, 2025 5:51 PM To: Marina Fizgeer <marina.fizg...@rbbn.com<mailto:marina.fizg...@rbbn.com>>; Andrew Stone (Nokia) <andrew.stone=40nokia....@dmarc.ietf.org<mailto:andrew.stone=40nokia....@dmarc.ietf.org>> Cc: Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org> Subject: [EXTERNAL] Re: PCE WG Minutes for IETF 123 Hi Marina, I'm a bit worried that way it may be too granular, but let's see if we can come with more usecases (more complex design -> lower chance that it will be adopted by implementations). If there is limited number of use cases, then maybe single flag will be sufficient with description of applicable usecases. For adding that flag to more generic place - at least I'm not aware about any PCEP draft related to PCE initiated LSPs, which can be used as a vehicle, but I can imagine either renaming current draft (since it is 00 version), creating new separate draft for that purpose or using something "generic" draft like operational draft (draft-many-pce-stateful-amendment after splitting). Regards, Samuel From: Marina Fizgeer <marina.fizg...@rbbn.com<mailto:marina.fizg...@rbbn.com>> Date: Monday, 4 August 2025 at 16:26 To: Samuel Sidor (ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>>, Andrew Stone (Nokia) <andrew.stone=40nokia....@dmarc.ietf.org<mailto:andrew.stone=40nokia....@dmarc.ietf.org>> Cc: Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>, pce@ietf.org<mailto:pce@ietf.org> <pce@ietf.org<mailto:pce@ietf.org>> Subject: RE: PCE WG Minutes for IETF 123 Hi, Samuel. Thank you for reply. Maybe one of the options is to use this "D" flag with some let's say "bit string" of use cases. In this "bit string" each bit will indicate specific use case (also will be possible to have combination of use cases). For example, Flag D (down) indicates that LSP can be created even some validation is failed, but LSP will be in down state If flag D is 1: bit#0 - if specified binding value is unavailable bit#1 – if specified path (ERO list) is not passed resolution ….. and so on. Such way needed cases can be added in the relevant drafts for specific use cases , but will not be used in case, when such LSP will never go up. And if yes, flag D seems to be added to some more generic place, related to PCE initiated things Best regards, [Logo]<https://ribboncommunications.com> Marina Fizgeer Sr. Manager, Systems Architecture | Ribbon M +972.544860016 Petah Tikva, Israel [Banner]<https://ribboncommunications.com/?_gl=1*6qlbuc*_gcl_au*MjA3NzE5OTk5NC4xNzI4NDE0NDY4*_ga*NTIxNzg1MDgxLjE3Mjg0MTQ0NjM.*_ga_VCEZ9Q3S3Y*MTcyODQ1MjEzMC4yLjEuMTcyODQ1MjE4OS4xLjAuMTA4NjExNTU4> From: Samuel Sidor (ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>> Sent: Monday, August 4, 2025 11:00 AM To: Marina Fizgeer <marina.fizg...@rbbn.com<mailto:marina.fizg...@rbbn.com>>; Andrew Stone (Nokia) <andrew.stone=40nokia....@dmarc.ietf.org<mailto:andrew.stone=40nokia....@dmarc.ietf.org>> Cc: Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org> Subject: [EXTERNAL] Re: PCE WG Minutes for IETF 123 Hi Marina, Thanks for that suggestion, I like that idea. I assume that we would need to identify cases, where it makes sense to allow LSP creation (cases, where LSP is down temporarily and there is chance that it will go up later - e.g. ERO or BSID validation) and those, where it still makes sense to reject creation, because it is clear that such LSP will never go up (e.g. LSP with some unsupported feature enabled). Can you (or other WG members) think about any other use cases for that flag? I'm just thinking if there can be any cases, which would not fit into group described above. Regards, Samuel From: Marina Fizgeer <marina.fizg...@rbbn.com<mailto:marina.fizg...@rbbn.com>> Date: Sunday, 3 August 2025 at 14:16 To: Andrew Stone (Nokia) <andrew.stone=40nokia....@dmarc.ietf.org<mailto:andrew.stone=40nokia....@dmarc.ietf.org>>, pce@ietf.org<mailto:pce@ietf.org> <pce@ietf.org<mailto:pce@ietf.org>>, Samuel Sidor (ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>> Cc: Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> Subject: RE: PCE WG Minutes for IETF 123 Hi, PCE WG, Samuel, I have some thought/suggestion regarding the new D flag in the draft https://datatracker.ietf.org/doc/draft-sidor-pce-binding-label-sid-extensions/<https://datatracker.ietf.org/doc/draft-sidor-pce-binding-label-sid-extensions>. I believe that it is a very good idea to have such a flag, which gives the option to set an LSP, even if it hasn't passed validation, in a down state. I think it may be useful to expand the use of this flag to other cases and make it more generic. As an example, today PCE-init LSP can only be established if the resolution was successful. This may cause performance issues in the case of creating multiple LSPs in the single PCEInit message. Why not add such a flag in the case of creating a PCE-init LSP as well? If this flag is 'on' but the resolution fails, such an LSP will be set to a down state. I think we can find other use cases where the use of this flag can be helpful and convenient. What do you think? Best regards, [Logo]<https://ribboncommunications.com> Marina Fizgeer Sr. Manager, Systems Architecture | Ribbon M +972.544860016 Petah Tikva, Israel [Banner]<https://ribboncommunications.com/?_gl=1*6qlbuc*_gcl_au*MjA3NzE5OTk5NC4xNzI4NDE0NDY4*_ga*NTIxNzg1MDgxLjE3Mjg0MTQ0NjM.*_ga_VCEZ9Q3S3Y*MTcyODQ1MjEzMC4yLjEuMTcyODQ1MjE4OS4xLjAuMTA4NjExNTU4> From: Andrew Stone (Nokia) <andrew.stone=40nokia....@dmarc.ietf.org<mailto:andrew.stone=40nokia....@dmarc.ietf.org>> Sent: Tuesday, July 29, 2025 11:18 AM To: pce@ietf.org<mailto:pce@ietf.org> Subject: [EXTERNAL] [Pce] PCE WG Minutes for IETF 123 Hi PCE WG, Please find the minutes for PCE WG session at https://datatracker.ietf.org/meeting/123/materials/minutes-123-pce-202507250730-00 Thanks to those who contributed to the minutes. Please reach out to pce-cha...@ietf.org<mailto:pce-cha...@ietf.org> in case any correction needs to be made. Thanks, Andrew (PCE Secretary) Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
