Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.
Thank you for the work put into this document. I have not had time to review in details though :( but I appreciated the detailed description as well as the useful time diagrams. Please find below one blocking DISCUSS point (which may be my bad understanding), some non-blocking COMMENT points (but replies would be appreciated). I hope that this helps to improve the document, Regards, -éric == DISCUSS == -- Section 7.3.1 -- LINKLOCAL-IPV6-ID-ADDRESS TLV: I fail to understand why there are two addresses in this TLV while others have one one ? Also is 'local' and 'remote' really global addresses ?
== COMMENTS == A minor comment: the abstract is clear but probably a little too long for an abstract. -- Section 7.3 -- Just wonder why LINKLOCAL-IPV6-ID-ADDRES is not mentioned in this section but well in the next one ?
Thank you to Yaron Sheffer for the SECDIR review and the updates made as a result to improve the Security Considerations. I endorse the revised text that minimally RECOMMENDs the use of “mutually-authenticated and encrypted sessions.” My question is why can’t we go even further and require (use MUST) this crucial provisioning channel always be protected. When would we NOT want to use TLS? I appreciate that mandating the use of security primitives in routing is challenging due to a long tail of legacy investment. However, this extension seems like a near "green field" focused on a modern, SDN architecture which seems unlikely to have less capable legacy elements.
I agree with Roman about the prospects for ensuring a solid security baseline with what is essentially greenfield deployment. (throughout) Is the TLV LSP-IDENTIFIER or LSP-IDENTIFIERS (with final 'S')? Thanks to Yaron Sheffer for the secdir reviews, and to the authors for updating in light of that review. I note in a few places in the section-by-section comments that the figures seem to indicate a 'D' flag in PCInitiate and PCUpd messages, and the only D flag I see mentioned in the prose is the Delegate flag in a PCRpt. This seems particularly important to check and get right (though I admit that I could just be missing something). Section 1 A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the LSP can be calculated/setup/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network devices along the path while leveraging the existing PCE technologies as much as possible. nit: "each network device" singular. Section 2 The terminology used in this document is the same as that described in the draft [RFC8283]. "That RFC doesn't look like a draft to me" Section 3 This document also allows a case where the label space is maintained by the PCC itself, and the labels are allocated by the PCC, in this case, the PCE should request the allocation from PCC as described in Section 5.5.8. nit: comma splice. Section 4 4. PCEP procedures need to provide a mean to update (or clean up) the label-download entry to the PCC. 5. PCEP procedures need to provide a mean to synchronize the labels between the PCE and the PCC via PCEP messages. nits: "provide a means" plural (twice); s/the label-download entry/label entries downloaded/ (I think) Section 5.4 A legacy PCEP speaker (that does not recognize the PCECC Capability sub-TLV) will ignore the sub-TLV in accordance with [RFC8408] and [RFC5440]. As per [RFC8408], the legacy PCEP speaker (that does not support PST), it will: Sending a PCErr for an unrecognized PST in the PATH-SETUP-TYPE-CAPABILITY would break extensibility; the 21/1 error type/value pair is only used in RFC 8408 when a PST is attempted to be used in a PCRpt, PCInitiate, or PCUpd. I think we should just say that it ignores the PST in the PATH-SETUP-TYPE-CAPABILITY TLV. Section 5.5.1 An LSP-IDENTIFIER TLV MUST be included for PCECC LSPs, the tuple uniquely identifies the LSP in the network. [...] Which tuple? Also, RFC 8231 says that the LSP-IDENTIFIERS TLV (note final 'S') must be used for RSVP-signaled LSPs, but PCECC is not (to my knowledge) requiring the use of RSVP. Do we need to say anything to generalize LSP-IDENTIFIERS for other use? The ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C (Create) flag (see [RFC8281]) in the LSP object of the PCRpt message to the PCE in the initial exchange. The PCC responds with a PCRpt message with the status set to "GOING-UP" and carrying the assigned PLSP-ID (see Figure 1). [...] nit: "responds" feels a bit out of place here, since the first sentence has already talked about setting flags in the PCRpt. Switching the order of the sentences might help, but there still wouldn't be a very clear connection in the prose between the PCRpt and triggering PCInitiate. Each PCC further responds with the PCRpt messages including the central controller instruction (CCI) and the LSP objects. The PCC responds with a PCRpt message to acknowledge the central controller instruction. Likewise, the second "responds" here feels out of place. |PCC | | PCE | |ingress| +-------+ +------| | | | PCC +-------+ | | transit| | | +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP |PCC +--------+ | | Initiate [sorry for truncation] In the PCInitiate line, what does D=1 refer to? The only mention of a D flag I can find is that the PCC must set D=1 in the initial PCRpt to delegate the LSP. | | |<---PCUpd,PLSP-ID=2,PST=TBD1,D=1------| PCECC LSP | | | (UP) | Update Likewise, what is the 'D=1' in PCUpd? (Both remarks seem to apply to Figure 2 as well.) - The O bit is set as before (and thus not included) Figure 2: PCE-Initiated PCECC LSP (PCC allocation) (It doesn't look like we currently indicate the O bit in Figure 1, so this remark feels a little out of place. We do indicate the O bit in Figure 3, though.) Section 5.5.3 As per [RFC8281], following the removal of the Label forwarding instruction, the PCC MUST send a PCRpt message. The SRP object in the PCRpt MUST include the SRP-ID-number from the PCInitiate message that triggered the removal. The R flag in the SRP object MUST be set. This text seems to indicate that the R flag is set in the SRP object in the PCRpt, but this does not seem to be reflected in Figure 5. Section 5.5.4 New CC-IDs are used to identify the updated instructions, the identifiers in the LSP object identify the existing LSP. [...] nit: comma splice. | | |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC | | | SRP=S | LSP Update (I remain unsure about the D flag in the PCUpd.) Section 5.5.8 the Label. If the allocation is successful, the PCC MUST report via the PCRpt message with the CCI object. Else, it MUST send a PCErr message with Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 ("Invalid CCI"). If the value of the Label in the CCI object is valid, but the PCC is unable to allocate it, it MUST send a PCErr message with Error-Type = TBD5 ("PCECC failure") and Error Value = TBD10 ("Unable to allocate the specified CCI"). I might be misreading, but this seems to say that if allocation failed but the value of the label in the CCI object is valid, you have to send *two* PCErr messages, one with TBD9 and one with TBD10 (there are two MUST-level requirements that seem to both apply). I mostly assume that just one would suffice, so a bit of rewording might be in order. If the PCC wishes to withdraw or modify the previously assigned label, it MUST send a PCRpt message without any Label or with the Label containing the new value respectively in the CCI object. The PCE would further trigger the removal of the central controller instruction as per this document. This seems quite vague about which CCI is to be removed from where. Section 6.1 At most two instances of the CCI object can be included, in the case of transit LSR to encode both in-coming and out-going label forwarding instructions. Other instances MUST be ignored for P2P LSP. [...] It's a little hard to square up "at most two instances" and "other instances MUST be ignored", even if the former doesn't use normative language. Section 7.1.1 o L bit (Label): if set to 1 by a PCEP speaker, the L flag indicates that the PCEP speaker support and willing to handle the PCECC nits: "supports and is willing" Section 7.3 CC-ID: A PCEP-specific identifier for the CCI information. A PCE creates a CC-ID for each instruction, the value is unique within the scope of the PCE and is constant for the lifetime of a PCEP session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be used. In the vein of draft-gont-numeric-ids-sec-considerations, please include some discussion on whether the uniqueness property is the only one needed (e.g., no ordering or gap detection), as well as some analysis of what information is leaked (including side channels) if the CC-ID is revealed to outside parties. My preliminary instinct is that if the value is only in scope for a single live PCEP session (i.e., two fixed peers) and the session is protected by TLS, there is no harm in doing sequential allocation and that makes ensuring uniqueness easier, but there are any number of ways in which such a trivial analysis could be flawed. Section 7.3.1 IANA already shows IPV4-ADDRESS and IPV6-ADDRESS TLVs allocated by RFC 8779, with what appears to be identical structure to these. Why are new TLV types necessary? Section 9 I agree with the secdir reviewer that it would be worthwhile to discuss authorization as well as authentication. In a system with the privileged central controller, confirming that a given authenticated entity is authorized to act as the central controller is important to the overall security of the system (so that a compromised PCC node cannot claim to be a PCE to other, uncompromised, PCC nodes). This might be done, for example, via an attribute in the PCE's X.509 certificate used for PCEPS or a local policy with a specific accept-list of X.509 certificate. Section 9.1 I think we should reiterate the guidance that PCCs need to check that labels provided by the PCE are in the proper range. general precaution, it is RECOMMENDED that this PCEP extension be activated on mutually-authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using TLS [RFC8253], as per the recommendations and best current practices in [RFC7525]. It's probably best to cite this as BCP 195, as there is likely to be an updated version in the next couple years. [RFC8281] provides a mechanism to protect PCC by imposing a limit. The same can be used for the PCECC operations as well. nit: either "PCCs" or "the PCC". Section 11.6 IANA is requested to create a new sub-registry to manage the Flag field of the CCI object called "CCI Object 16-bits Flag Field". New Are these flags expected to be specific to the Object-Type 1 (MPLS Label) CCI Object? If so, perhaps the registry name should indicate that. Section 13.2 We generally see RFC 8126 listed as normative when used for the registration procedures when defining a new registry. Per https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ it seems that the recommended behavior with RFCs 8253 and 7525 should make them normative references.
In Section 2, RFC 8283 isn't a "draft". In Section 5.5.1: Once the label operations are completed, the PCE SHOULD send a PCUpd message to the ingress PCC. Why "SHOULD"? Is there another option? Why might an implementer do something else? The SHOULDs elsewhere in Section 5 are probably worth a second look too.
(0) The fact that the procedures (§5) are presented before introducing the messages/objects (§6-7) makes reading this document harder and more complex than it has to be. Consider changing the order or at least adding forward references in §5. (1) §5.2: Is there a reason for the messages from rfc8231 to be in parenthesis? (2) §5.4: The PCECC-CAPABILITY sub-TLV SHOULD NOT be used without the corresponding Path Setup Type being listed in the PATH-SETUP-TYPE- CAPABILITY TLV. If it is present without the corresponding Path Setup Type listed in the PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be ignored. When is it ok to use the PCECC-CAPABILITY sub-TLV without the corresponding PST? If the result is that it will be ignored, then I don't understand why the use of both is not required. (3) §5.5.1/§5.5.4: "ingress MAY further choose to deploy a data plane check mechanism and report the status back to the PCE" Is this (checking and reporting) specified somewhere? Because you're using normative language, please add a reference. A similar statement is made in §5.5.7: "ingress PCC MAY choose to apply any OAM mechanism to check the status of LSP in the Data plane and MAY further send its status in a PCRpt message to the PCE". (4) §5.5.3: s/central controller instructions...is done/central controller instructions...are done (5) §5.5.8: "The PCC SHOULD allocate the Label and SHOULD report to the PCE using the PCRpt message." When is it ok for the PCC to not allocate and/or report? IOW, why are these actions only recommended and not required? Note that the very next paragraph requires the behavior. (6) §7.3/§7.3.1: In the out-label case, "it is mandatory to encode the next-hop information". Should this information point at a directly connected IP address/interface, or can it point at a remote next-hop (which may be resolved through a routing protocol)? What if the expected conditions are not met?
Hi, Thanks for the document, I have not had time to review in detail. The length of the abstract does stand out to me, and it might be helpful if it could be shortened. E.g. I suspect that the first two paragraphs are probably not required in the abstract and are best covered in the introduction. On section 10: A PCE or PCC implementation SHOULD allow to configure to enable/ disable PCECC capability as a global configuration. => A PCE or PCC implementation SHOULD allow the PCECC capability to be enabled/disabled as part of the global configuration. Also probably change "is enabled on the PCEP session" to "is enabled on a PCEP session"? Regards, Rob