[Pce] Re: I-D Action: draft-ietf-pce-pcep-extension-native-ip-36.txt

[John Scudder <[e-mail]>]

Hi Aijun, all,

> On Aug 23, 2024, at 5:58 AM, Aijun Wang <[e-mail]> 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.