Hi,
I had a quick look at this draft as part of the adoption poll.
It is not unusual for a document being considered for adoption to need
additional work. This document certainly needs some attention. I have
included some issues and nits below, after my considerations with
respect of adoption.
Best,
Adrian
= Adoption Considerations =
This work seems to be in scope of the PCE charter.
---
I am appreciative of the Implementation Considerations section. I think,
in order to adopt this, we need to know that the features defined are of
interest to more than one vendor. So I would like to hear about that
(not necessarily in the draft - the mailing list would do).
---
Has this work been shared with the BFD working group and (in view of the
statement that it is particularly driven by SR) the SPRING working
group? It would be good to understand whether they consider it to be
useful.
---
I don't believe the draft makes a good case for why we would use PCEP to
configure the use of BFD on a path. Presumably BFD is used today on
paths computed by PCE or installed by an active PCE. Why are these
other mechanisms not considered adequate? Section 3 which is intended to
motivate the work, seems a bit thin.
- 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?
- "As the parameters are associated to LSPs or tunnels, they are
exchanged via PCEP" seems to be a non sequitur.
- The final sentence in the section is definitely true, but it does not
form part of the motivation.
= Issues =
The Abstract says:
This document proposes extension to PCEP to configure LSP parameters.
Some of LSP parameters are needed to configure S-BFD for candidate
paths.
Does this document define any PCEP extension for anything other than
BFD? I didn't find any.
---
The Abstract says:
The need for these
definitions first appeared for Segment Routing path setup type, both
MPLS and IPv6 data planes of SR.
I am unsure why this should be mentioned in the Abstract, especially
given the previous sentence.
---
The Introduction mentions the use of PCEP between two PCEs. Would the
extensions defined in this document be used between PCEs?
---
Section 3 needs a reference when it says "S-BFD protocol". Presumably
the various parameters also need to be referenced back to the S-BFD spec
---
4.2 has:
In some implementations there is limitation that LSPs in the same
association group must have same S-BFD parameter values.
Editor note: Alternatively, it can be defined implicitly as follows:
If the LSP-SBFD TLV is not received from PCEP peer but there is S-BFD
for that LSP then S-BFD shall be removed for specified LSP.
This is a protocol spec not a description of implementations!
Anyway, why would it be legitimate to require that all LSPs in a group
must have the same S-BFD values?
See also section 6.
---
The use of BCP 14 language needs to be cleaned up:
- There are some lower case "shall", "must", and "may"
- "IGNORE" is not a BCP 14 term
- Where you have "SHOULD", you need to also have a "MAY" and describe
how the implementation chooses.
- Check the use of "MAY" to be sure that you have described why an
implementation might make that choice.
---
4.1 has:
The S-BFD parameters are only meant to be used for SR LSPs and with
PCEP peers which advertise SR capability.
This seems to contradict:
- The Abstract which says:
The mechanism proposed in this document is
applicable to all path setup types.
- Section 4.1, itself, which says:
Defining S-BFD parameters via PCEP MAY be also used together with a
PCE as a Central Controller
---
In 4.1
Defining S-BFD parameters via PCEP MAY be also used together with a
PCE as a Central Controller (PCECC) architecture and procedures
[RFC9050].
Firstly, this should be a lower case "may".
Secondly, this text is very underspecified (you need to describe what
this means - is this link-level BFD you are talking about, or what?)
---
If I read this right, the S-BFD parameters are only used with a stateful
PCE. That is, the PCE configures the use of BFD on a path that it is
controlling.
If that is the case, why do you need a whole new Capabilities TLV? Why
not use a new bit in the STATEFUL-PCE-CAPABILITY TLV Flag Field?
---
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.
---
Section 8 is obviously wrong as you are adding a new feature which, if
tampered with, could compromise fault detection (false positives or
false negatives) with important consequences.
= Nits =
It is always a good idea for authors to run idnits and clean up any
warnings. In this case, there are some issues with the references.
---
There is some garbled XML around Figure 2
---
The Requirements Language needs to move from the document header and be
placed in its own section (probably 2.1).
---
4.3.1
A legacy PCEP speaker (that does not recognize the
LSP-SBFD-Capability TLV) MUST ignore the TLV in accordance with
[ RFC5440].
s/MUST/will/ as you cannot normatively instruct an implementation that
does not support this spec.
From: Dhruv Dhody <d...@dhruvdhody.com>
Sent: 04 January 2025 11:07
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
