Hi, John: You are right. For controller-based or controller-assisted architecture, the interaction between the PCE and PCC is as important as the peer routers within the traditional distributed routing architecture-----we must assure/confirm the reception of the control message among the entities, or else, the out-of-sync may occurs.
I have updated the document again, with "SHOULD" be replaced with "MUST" for the necessary report message from PCC when it receives the instruction from the PCE. And, also to Roman: I have reverted back to the non-RFC2119 keyword for the description of IANA considerations in section 13, that is, revert the "SHOULD" to "should". Thanks again for your thoughts, comments and suggestions! Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 【外部账号】 John Scudder 发送时间: 2024年8月23日 23:47 收件人: Aijun Wang <wangai...@tsinghua.org.cn> 抄送: The IESG <i...@ietf.org>; pce@ietf.org; draft-ietf-pce-pcep-extension-native...@ietf.org 主题: Re: [Pce] I-D Action: draft-ietf-pce-pcep-extension-native-ip-36.txt Hi Aijun, all, > On Aug 23, 2024, at 5:58 AM, Aijun Wang <wangai...@tsinghua.org.cn> 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 -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
