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>
Date: Saturday, January 4, 2025 at 6:08 AM
To: 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>
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/
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
