Hi Aijun, all,
> On Aug 23, 2024, at 5:58 AM, Aijun Wang <[email protected]> wrote:
>
> I updated the draft again according to the comments/suggestions that received
> until now, please give your further comments on this version to see whether
> it addresses all issues that you concerned.
>
> Thanks for your reviews and suggestions to forward this document!
I've reviewed the diff between 34 and 36.
Most of the introduced SHOULDs are OK with me. I might be pickier about them if
this were on the Standards Track, but I think we can call it "good enough" for
this maturity level. There are a few I want to discuss further, though, below.
Most of the cases I want to discuss are clauses that say the PCC SHOULD send an
error or status report, implying that sometimes it's OK not to send such a
report. While I can see that sometimes it might be ok to not take an action
(for example not install a route, due to local policy or local resource
exhaustion) I would think that the controller still needs to know the resulting
status. It's hard for me to see how it's ever OK in a controller-based
architecture, for elements of the network to silently fail to execute a
command. The controller's state would become desynchronized and at that point,
things start going badly. As an example, consider the case where a PCC fails to
install a route. If it reports the failure, the controller can try a different
path. If it doesn't report the failure, there's persistent traffic loss.
In addition, we've already covered the MUSTs that were introduced in the IANA
Considerations section. As previously noted, IMO those should revert to non-RFC
2119 words.
Thanks,
--John
### Section 6.1
If the established BGP session is broken, the PCC MUST report such
information via PCRpt message with the status field set to "BGP
session down" in the associated BPI Object. The error code field
within the BPI object SHOULD indicate the reason that leads to the
BGP session being down. In the future, when the BGP session is up
again, the PCC MUST report that as well via the PCRpt message with
the status field set to "BGP Session Established".
Under what conditions would it be OK to send a report and *not* have the error
code field set as described? I can't think of a situation like that, which
suggests to me that either the SHOULD ought to be MUST, or the SHOULD could
revert to "should" or similar, e.g. "the error code field indicates the reason".
### Section 6.2
When the PCC receives the EPR and the CCI object (with the R bit set
to 0 in the SRP object) in the PCInitiate message, the PCC SHOULD
install the explicit route to the peer in the RIB/FIB.
I am OK with the above SHOULD. For example, I can imagine that the PCC might
not install the explicit route because of local configuration, or because of
resource constraints.
When the PCC installs successfully the explicit route to the peer, it
SHOULD report the result via the PCRpt messages, with the EPR object
and the corresponding SRP and CCI objects included.
Can you please explain to me what the consequence would be if the PCE sends the
explicit route to the PCC, and the PCC silently fails to install it? It seems
to me this should either be MUST, or should revert to some looser language
("should", or "it reports the result"). Using SHOULD implies there is some case
in which it's fine or foreseeable not to send the error.
When the PCC receives the EPR and the CCI object with the R bit set
to 1 in the SRP object in the PCInitiate message, the PCC MUST remove
the explicit route to the peer that is indicated by the EPR object.
The new MUST seems fine.
When the PCC has removed the explicit route that is indicated by this
object, it SHOULD report the result via the PCRpt message, with the
EPR object included, and the corresponding SRP and CCI object.
Again I don't understand when it's OK to not send back the report. I guess it
is somewhat less bad than the case discussed above, but it's on the same
spectrum, so again I think this is either MUST or "it reports the result".
### Section 6.3
When the PCC has successfully sent the prefixes to the appointed BGP
peer, it SHOULD report the result via the PCRpt messages, with the
PPA object and the corresponding SRP and CCI objects included.
...
When the PCC withdraws successfully the prefixes that are indicated
by this object, it SHOULD report the result via the PCRpt message,
with the PPA object included, and the corresponding SRP and CCI
objects.
Similar analysis to the above.
### Section 9
When the PCE sends out the PCInitiate message with the BPI object
embedded to establish the BGP session between the PCC peers, the PCC
SHOULD report the BGP session status. For instance, the PCC could
respond with "BGP Session Establishment In Progress" initially and on
session establishment send another PCRpt message with the state
updated to "BGP Session Established". If there is any error during
the BGP session establishment, the PCC SHOULD indicate the reason
with the appropriate status value set in the BPI object.
Upon receiving such key information, the BGP module on the PCC SHOULD
try to accomplish the task appointed by the PCEP protocol and report
the successful status to the PCEP modules after the session is set
up.
Similar concerns to the above.
### Section 13
In this setup, the BGP sessions, prefix advertisement, and explicit
peer route establishment are all controlled by the PCE. See
[RFC4271] for security consideration of classical BGP implementation,
and [RFC4272] for classical BGP vulnerabilities analysis. Security
considerations in [RFC5440]for basic PCEP protocol, [RFC8231] for
PCEP extension for stateful PCE and [RFC8281] for PCE-Initiated LSP
setup SHOULD be considered.
The above SHOULD is more appropriately "should" IMO. It's not any kind of
protocol specification or even operational procedure specification. It's
advising a reader what to look at when reasoning about the protocol, which is
beyond the usual scope of RFC 2119.
_______________________________________________
Pce mailing list -- [email protected]
To unsubscribe send an email to [email protected]
