Hi authors of draft-fizgeer-pce-pcep-bfd-parameters, 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? * 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?) * 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)? * 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. * 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) * 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? 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. * Text of sections 4.3.1and 4.3.2.2 is included in "figure" element even if it is not supposed to be * Section 4.2.3 contains word "Procedure", which does not seem to belong to anything * Section 7.2 has some visible XML tags * "PCEP Tunnel" in Terminology should be on separate line * Please expand acronyms (e.g. LSPA in Introduction, PCEP in abstract and document title,... * Inconsistent acronym, sometimes SBFD, sometimes S-BFD * "...then it may IGNORE it..." - is it supposed to be "...then it MAY ignore it..."? Thanks, Samuel From: Dhruv Dhody <d...@dhruvdhody.com> Sent: Saturday, January 4, 2025 12:07 PM To: pce@ietf.org Cc: pce-chairs <pce-cha...@ietf.org>; draft-fizgeer-pce-pcep-bfd-paramet...@ietf.org Subject: [Pce] WG Adoption of draft-fizgeer-pce-pcep-bfd-parameters-03 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/ 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
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
