Hi Marina, Thank you for the reply. Regarding…
> BFD is needed also for fast protection. In SR-TE with AS it’s useful. There > is no other way to configure S-BFD per LSP, only via PCEP. Yes, agreed on BFD usefulness in SR-TE, no debate there. The part I’m doubting and questioning is whether bfd-specific pcep-tlv encodings is required in PCEP itself, and the value it gives, maintenance it will require, and what-else-will-come in the future-for-pcc-config compared to protocols that are specialized in device object configuration. When it comes to PCE-Init LSPs, as commented, it can be achieved with a policy/templating mechanism in PCEP without needing specific tlv encodings and still maintain multi-vendor/implementation interop because only PCC actually needs to see the values, which can be pre-established as an infrastructure operation - my assumption here is timers will be generally standardized across the node with a few flavors – not 100% unique for every LSP. > draft-alvarez-pce-path-profiles is expired in 2015. RFC9005 – defines to > use policies, but we don’t want to add new policy – why does it needed? An expired unadopted document vs unadopted document isn’t too far apart in my opinion, nothing is stopping draft-alvarez-pce-path-profiles from being revived and adopted like this proposal being created and adopted. Regardless, RFC9005 and similar association achieves similar – I mentioned draft-alvarez-pce-path-profiles purely as an additional example. In terms of why to use a policy/template-based mechanism – I see it saving new PCEP encodings, thus new software on both PCC and PCE, and PCEP interop testing, for scenarios for this and future PCC-only-specific config. Thanks again, Andrew From: Marina Fizgeer <marina.fizg...@rbbn.com> Date: Thursday, January 30, 2025 at 6:10 AM To: Andrew Stone (Nokia) <andrew.st...@nokia.com>, Dhruv Dhody <d...@dhruvdhody.com>, pce@ietf.org <pce@ietf.org> Cc: pce-chairs <pce-cha...@ietf.org>, draft-fizgeer-pce-pcep-bfd-paramet...@ietf.org <draft-fizgeer-pce-pcep-bfd-paramet...@ietf.org>, Marina Fizgeer <marina.fizg...@rbbn.com> Subject: RE: WG Adoption of draft-fizgeer-pce-pcep-bfd-parameters-03 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi, dear WG and all, I’m working on new version of the draft – with some changes, not all. Hope, I’ll publish it in some number of days. Thank you all, who spent time and gave the comments. It’s very important for us and for who really think to use this draft. Some my answers are below: Andrew Stone, my explanation for your mail: S-BFD is needed also for fast protection. In SR-TE with AS it’s useful. There is no other way to configure S-BFD per LSP, only via PCEP. draft-alvarez-pce-path-profiles is expired in 2015. RFC9005 – defines to use policies, but we don’t want to add new policy – why does it needed? Boris Hassanov , my answers and explanation for your mail: * This draft can be used not for SR-TE policy, but also for other traffic types, as example – RSVP-TE. I already correct description in the new draft version. * 4.2 " If B=0 and LSP-BFD-Parameters sub-TLV is received, then the PCEP speaker shall IGNORE the sub-TLV. Ignoring or saving the S-BFD configuration is implementation decision." -> "f B=0 and LSP-BFD-Parameters sub-TLV are received, when the PCEP speaker MAY IGNORE the sub-TLV. Ignoring or saving the S-BFD configuration is implementation decision. " In general, we can change it to implementation decision, we’ll think about it as in this case some flows/behavior shall be defined for interoperability. For example, if PCC shall save parameters even if B=0, and next time PCE can send B = 1 only? Right to now, we think in case of B = 1, PCE MUST send again all relevant parameters. But we’ll continue to think about such use cases. * 4.3 – will rephrase it as you suggested * 4.4 – we can have 2 managers (PCE and CLI, as example). We’ll add that it can be local policy in case of conflict or editing the same LSP from different managers. In some implementations it can be restricted – for example, PCE initiated LSP cannot be edited from CLI and vise versa. But here I’m not sure. We can have case that PCC supports S-BFD and PCE doesn’t. Then PCC user (CLI), maybe, shall be able to add/activate S-BFD for PCE initiated LSP. We’ll think about it. Editor notes also will be updated. * 6.1 There is peace of XML in the text already corrected in the new version. Reshad Rahman: Microseconds are changed to milliseconds in the new version Quan Xiong: I added reference to S-BFD [RFC7880] protocol standard. Meaning and using of parameters are explained in this RFC and not related to PCEP Adrian Farrel: * BFD WG and SPRING WG are aware of this draft. We did it already with the first version of it – MF: I’ll extend motivation section and will add more reasons and explanations. * Do the protocol parameters need to be exchanged between PCEP speakers, or do they need to be configured at the head end of the path? - MF: not needed to exchange as it is S-BFD * "As the parameters are associated to LSPs or tunnels, they are exchanged via PCEP" seems to be a non sequitur – MF: will rephrase * In Abstract – this document defines it special for S-BFD. Will update this part. * In section 3 reference to “S-BFD protocol” is added in the new version. * 4.2 – implementation issues: we can remove, but some errors shall be used (will think which) * The use of BCP 14 language – I’ll go and carefully check and correct these issues * 4.1 – I don’t so understand what is contradict * 4.1 – will update MAY as lower case, will add explanation, but S-BFD params are bound to LSP * This extension is relevant for stateful PCE, will add it. I checked STATEFUL-PCE-CAPABILITY TLV Flag Field. We can use some unused flag, but we didn’t want to extend common TLV for it. And in additional, it’s used for PCE only, but we need it for both PCE and PCC. Seems similar as it’s defined in separate capability for auto-bw as example (RFC8733). * I don't like that you use "PCEP peer" in 4.2. If the PCC sends the S-BFD info to the PCE, is the PCE able to use S-BFD on the path? I don't think so. Thus, you should reword these references in terms of "PCE" and "PCC" to make clear which is which - MF: S-BFD is in context of LSP * Section 8 – will rephrase and check security issues * XML issues are corrected, idnits – I always do it * About legacy speakers – agree and will update Samuel Sidor: A few comments from my side: * Abstract is saying that extension is applicable to all setup types, but 1st paragraph of overview section is saying: “The S-BFD parameters are only meant to be used for SR LSPs and with PCEP peers which advertise SR capability”, so is it really applicable to other setup types? MF: yes, I changed it * I can see association mentioned multiple times in the draft, but I don’t see any explanation saying how it is supposed/intended to be used. Section 8 is also talking about some new type of association being defined in the document, but I don’t see it defined anywhere. Can you explain purpose of that association? Is PCE suppose to use it somehow for PCC Initiated LSPs (e.g. in path-computation) or is PCC supposed to have some local configuration applied to PCE Initiated LSPs in same association group? (in such case, do we even need this draft at all?) MF: will add and rephrase * Introduction section is describing that extensions are applicable to stateless PCEP as well, but I can see only processing for stateful messages described. Is it really appliable to stateless as well? If yes, what is the added value (e.g. if BFD parameters exchanged are supposed to be used just for visualization/debugging purposes then stateless extension is really useless)? MF: will add that it’s for stateful only * Section 5 is describing that PCEP peer is supposed to send PCErr if discriminator is not in valid range, but that range is not defined anywhere. It would be good to at least add some references to BFD RFCs/drafts as references if you don’t want to define those ranges in the draft explicitly. MF: will add range as well as some additional errors. Not sure if it will be in the nearest version, maybe in the next one * Do you even need completely new capability TLV? Isn’t it sufficient to add new flag into “STATEFUL-PCE-CAPABILITY” (or “SR Capability Flag Field” if it is SR specific) MF: yes, we need it (please, see my answer above) * What is the added value of having “B flag” in “LSP S-BFD TLV” if B=0 is same as not having “LSP S-BFD TLV”. Does it make sense to have S-BFD specific sub-TLVs included even if S-BFD is disabled? MF: maybe it will be useful to some implementations. We’ll think about Other minor comments * “In some implementations there is limitation…” in Section 4.2 -> Isn’t that just implementation limitation? You already have “Implementation Note”, so drop it from here. MF: will do * Text of sections 4.3.1and 4.3.2.2 is included in “figure” element even if it is not supposed to be MF: will check * Section 4.2.3 contains word “Procedure”, which does not seem to belong to anything MF: will check * Section 7.2 has some visible XML tags MF: already corrected * “PCEP Tunnel” in Terminology should be on separate line MF: will correct * Please expand acronyms (e.g. LSPA in Introduction, PCEP in abstract and document title,… MF: will add * Inconsistent acronym, sometimes SBFD, sometimes S-BFD MF: will correct * “…then it may IGNORE it…” – is it supposed to be “…then it MAY ignore it…”? MF: will check and update Thank you and best wishes, [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.st...@nokia.com> Sent: Wednesday, January 29, 2025 18:03 To: Dhruv Dhody <d...@dhruvdhody.com>; pce@ietf.org Cc: pce-chairs <pce-cha...@ietf.org>; draft-fizgeer-pce-pcep-bfd-paramet...@ietf.org Subject: [EXTERNAL] Re: WG Adoption of draft-fizgeer-pce-pcep-bfd-parameters-03 Hi PCE WG, Authors, Thanks for the submitting and working on the document. It’s a very clear read. I initially had some interest on this document when it was presented in one of the IETF sessions, however, find myself retracting on how to achieve it with encodings. I view using PCEP direct payload encoding as valuable information exchange(config and/or state) when that exchange is mutually beneficial for each PCEP speaker to achieve interoperable path-computation/placement. For one-sided configuration, that can be conveyed alternatively with policy/template and/or out of band netconf/gnmi/snmp etc. i.e try to avoid using PCEP for just a network device configuration conduit. Configuring BFD on PCC seems very one sided / uni-directional in usefulness, as it seems to only be of benefit to the PCC local config, with minimal value return to PCE other than being a config conduit (or perhaps I’m missing something). Some follow up questions: * PCE already has operational state and active state in PcRpt, would knowing whether BFD is enabled/disabled be of benefit to PCE? * ->From my experience so far, no, not really. Knowing why BFD is failing operationally would be useful, but that’s beyond config enablement. * Is the use case for PcUpd to turn on/off BFD actually required? * ->My understanding is you’d generally decide upfront whether BFD is to be enabled or not and stick with it. * Similar to Cheng’s comment, it could be achieved via draft-alvarez-pce-path-profiles or RFC9005, Was that mechanism evaluated? * -> it fits nicely due to the one side, uni-directional scenario and would not need PCEP maintenance for any new BFD or other similar one-sided knobs. No new PCEP extensions required, but an informational document could be created to inform this is how you can use path profiles or association policy to achieve BFD config. Thanks! Andrew From: Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> Date: Saturday, January 4, 2025 at 6:08 AM To: pce@ietf.org<mailto:pce@ietf.org> <pce@ietf.org<mailto:pce@ietf.org>> Cc: pce-chairs <pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>, draft-fizgeer-pce-pcep-bfd-paramet...@ietf.org<mailto:draft-fizgeer-pce-pcep-bfd-paramet...@ietf.org> <draft-fizgeer-pce-pcep-bfd-paramet...@ietf.org<mailto:draft-fizgeer-pce-pcep-bfd-paramet...@ietf.org>> Subject: WG Adoption of draft-fizgeer-pce-pcep-bfd-parameters-03 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi WG, This email begins the WG adoption poll for draft-fizgeer-pce-pcep-bfd-parameters-03 https://datatracker.ietf.org/doc/draft-fizgeer-pce-pcep-bfd-parameters/<https://datatracker.ietf.org/doc/draft-fizgeer-pce-pcep-bfd-parameters> Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list. Please respond by Monday 20th Jan 2025. Please be more vocal during WG polls! Thanks! Dhruv & Julien 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
