Hi,
Here is my review of draft-ietf-pce-vn-association-05 as part of the WG last call. I think the document is technically ready to proceed, but it needs quite a bit of work to polish the text. After the number of edits I am proposing I feel like I have rewritten the document! My comments are below. Thanks, Adrian ==Minor== 3. In order to set up the end-to-end tunnel, multiple segments need to be stitched, by the border nodes in each domain who receives the instruction from their child PCE (PNC). What end-to-end tunnel? This has not been mentioned before and I can't see one in the figure. --- 3. Local polices on the PCE MAY define the computational and optimization behavior for the LSPs in the VN. Why is this "MAY"? Isn't it good enough to write: Local polices on the PCE define the computational and optimization behavior for the LSPs in the VN. --- 3. If an implementation encounters more than one VNAG, it MUST consider the first occurrence and ignore the others. I think... If an implementation encounters more than one VNAG object in a PCEP message, it MUST process the first occurrence and it MUST ignore the others. --- 3. Operator-configured Association Range MUST NOT be set for this association-type and MUST be ignored. I know what you are trying to say, but you have crossed the line into describing implementations. Perhaps OLD This Association-Type is dynamic in nature and created by the Parent PCE (MDSC) for the LSPs belonging to the same VN or customer. These associations are conveyed via PCEP messages to the PCEP peer. Operator-configured Association Range MUST NOT be set for this association-type and MUST be ignored. NEW The Association IDs (VNAG IDs) for this Association Type are dynamic in nature and created by the Parent PCE (MDSC) for the LSPs belonging to the same VN or customer. Operator configuration of VNAG IDs is not supported so there is no need for an Operator-configured Association Range to be set. Thus, the VN Association Type (TBD1) MUST NOT be present in the Operator-Configured Association Range TLV if that TLV is present in the OPEN object. If an implementation encounters the VN Association Type in an Operator-Configured Association Range TLV, it MUST ignore the associated Start-Assoc-ID and Range values. END --- 4. o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier. It is confusing that you say VN Identifier (which sounds like VNAG identifier), but then the text and figure shows "VN name" or "Virtual Network Name". You need to: - select Identifier or Name - select VN or Virtual Network --- 4. (for VIRTUAL-NETWORK-TLV) Length: Variable Length Length of what and in what units? Just the Virtual Network Name or the whole TLV? Probably in octets. What is the maximum allowed value? Surely not 2^16. --- 4. How does internationalization work for the Virtual Network Name? Why is ASCII acceptable? --- 4. Does the Virtual Network Name need to be unique across all VNAGs? I suspect that it doesn't because its use is basically out of scope of this work. --- Does section 5 add anything to the document? There has already been discussion of parent and child PCEs and a lot of the material in this section is a direct quote from elsewhere in the document. I would suggest a very hard look to see whether anything needs to be retained or the whole section can be removed. --- 9.6 I think the whole point of this document is to change network operations --- ==Nits== LSP is going to need to be expanded on first use in each of: - the document title - the abstract - section 1 --- Abstract s/extend/extend the/ s/virtual network control/control of virtual networks/ s/using PCE/using the PCE/ --- 1. para 1 Should include a reference to RFC 5440 OLD computations in response to Path Computation Clients' (PCCs) requests. NEW computations in response to requests from Path Computation Clients (PCCs). END --- 1. OLD A stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources for its computations. NEW For its computations, a stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources. END --- 1. s/to define association/to define associations/ --- ACTN needs to be expanded on first use. --- 1. The last three paragraphs seem to introduce material in the wrong order. I think you need four paragraphs: - 8453, introduce ACTN and VN. Include the explanation of VN and customer from the final paragraph - 8637 paragraph as is - Remainder of the text from the first para on the need (starting at "In this context..."). - The statement of what this document is. So, something like (with nit fixes)... [RFC8453] introduces a framework for Abstraction and Control of TE Networks (ACTN) and describes various Virtual Network (VN) operations initiated by a customer or application. A VN is a customer view of the TE network. Depending on the agreement between client and provider, various VN operations and VN views are possible. [RFC8637] examines the PCE and ACTN architectures and describes how the PCE architecture is applicable to ACTN. [RFC6805] and [RFC8751] describes a hierarchy of stateful PCEs with Parent PCE coordinating multi-domain path computation function between Child PCEs, and thus making it the base for PCE applicability for ACTN. In this text child PCE would be same as Provisioning Network Controller (PNC), and the parent PCE as Multi-domain Service Coordinator (MDSC) [RFC8453]. In this context, there is a need to associate a set of LSPs with a VN "construct" to facilitate VN operations in the PCE architecture. This association allows a PCE to identify which LSPs belong to a certain VN. The PCE could then use this association to optimize all LSPs belonging to the VN at once. The PCE could further take VN- specific actions on the LSPs, such as relaxation of constraints, policy actions, setting default behavior, etc. This document specifies a PCEP extension to associate a set of LSPs based on Virtual Network (VN) (or customer). --- 3. s/but not limited/but is not limited/ OLD o Path Computation: When computing path for a LSP, the impact of this LSP, on the other LSPs belonging to the same VN is useful to analyze. The aim would be optimize overall VN and all LSPs, rather than a single LSP. Also, the optimization criteria such as minimize the load of the most loaded link (MLL) [RFC5541] and other could be applied for all the LSP belonging to the same VN, identified by the VN association. NEW o Path Computation: When computing a path for an LSP, it is useful to analyze the impact of this LSP on the other LSPs belonging to the same VN. The aim would be optimize all LSPs belonging to the VN rather than a single LSP. Also, the optimization criteria (such as minimizing the load of the most loaded link (MLL) [RFC5541]) could be applied for all the LSPs belonging to the VN identified by the VN association. END --- 3. OLD o Path Re-Optimization: The child PCE or the parent PCE would like to use advanced path computation algorithm and optimization technique that consider all the LSPs belonging to a VN/customer and optimize them all together during the re-optimization. NEW o Path Re-Optimization: The PCE would like to use advanced path computation algorithms and optimization techniques that consider all the LSPs belonging to a VN/customer, and optimize them all together during the path re-optimization. END --- 3. OLD This association is useful in PCEP session between parent PCE (MDSC) and child PCE (PNC). NEW This association is also useful in a PCEP session between a parent PCE (MDSC) and a child PCE (PNC). END s/refer/refers/ s/and the network resources/and network resources/ s/operator policy and/operator policy, and/ s/replied/returned/ s/part of response/part of the response/ --- 3. OLD The figure describes a typical VN operations using PCEP for illustration purpose. NEW Figure 1 shows an example of a typical VN operation using PCEP. END --- 3. s/the different domain is/the different domains are --- 3. The figure needs a number and a title. This will (of course) mean that figure numbering in the rest of the document is out by one. --- 3. The text after the figure is not specific to the figure, but makes it a lot easier to understand (for example, what is a VNAG in the figure?). Perhaps you should move that text up above the figure and above the reference to the figure. --- 3. OLD In this draft, this grouping is used to define associations between a set of LSPs and a virtual network, a new association group is defined below - o VN Association Group (VNAG) One new Association type is defined as described in the Association object - o Association type = TBD1 ("VN Association") for VNAG The scope and handling of VNAG identifier is similar to the generic association identifier defined in [RFC8697] . In this document VNAG object refers to an Association Object with the Association type set to "VNAG". NEW In this document we define a new association group called the VN Association Group (VNAG). This grouping is used to define the association between a set of LSPs and a virtual network. The Association Object contains a field to identify the type of association, and this document defines a new Association Type value of TBD1 to indicate that the association is a "VN Association". The Association Identifier in the Association Object is the VNAG Identifier and is handled in the same way as the generic association identifier defined in [RFC8697]. In this document, "VNAG object" refers to an Association Object with the Association type set to "VN Association". END --- 3. OLD [RFC8697] specify the mechanism for the capability advertisement of the association types supported by a PCEP speaker by defining a ASSOC-Type-List TLV to be carried within an OPEN object. This capability exchange for the association type described in this document (i.e. VN Association Type) MUST be done before using the policy association. Thus the PCEP speaker MUST include the VN Association Type (TBD1) in the ASSOC-Type-List TLV before using the VNAG in the PCEP messages. NEW [RFC8697] specifies the mechanism by which a PCEP speaker can advertise which association types it supports. This is done using the ASSOC-Type-List TLV carried within an OPEN object. A PCEP speaker MUST include the VN Association Type (TBD1) in the ASSOC-Type-List TLV before using the VNAG object in a PCEP message. END --- 3. s/Association-Type/Association Type/ --- 4. s/The format of VNAG/The format of VNAG object/ --- 4. To avoid duplication with what follows... OLD This document defines one mandatory TLV "VIRTUAL-NETWORK-TLV" and one new optional TLV "VENDOR-INFORMATION-TLV"; apart from this TLV, VENDOR-INFORMATION-TLV can be used to carry arbitrary vendor specific information. NEW This document defines one mandatory TLV "VIRTUAL-NETWORK-TLV" and one new optional TLV "VENDOR-INFORMATION-TLV". END --- 4. s/an unique/a unique/ --- 4. s/in VNAG object.If/in a VNAG object. If/ --- 5. OLD 5. Applicability to H-PCE architecture NEW 5. Applicability to H-PCE Architecture END --- 8.1 This document defines a new association type, originally defined in [RFC8697], for path protection. This is confusing text and can be safely deleted. --- 8.2 This document defines a new TLV for carrying additional information of LSPs within a path protection association group. This is plain wrong! Just delete it. --- 8.3 This document defines new Error-Type and Error-Value related to path protection association. This, too, is wrong. Just delete it. --- 8.3 s/new error values/new error value/ --- 9.1 s/MUST BE/must be/ From: Pce <pce-boun...@ietf.org> On Behalf Of Dhruv Dhody Sent: 22 February 2022 12:18 To: pce@ietf.org Cc: draft-ietf-pce-vn-associat...@ietf.org; pce-chairs <pce-cha...@ietf.org> Subject: [Pce] WGLC for draft-ietf-pce-vn-association-05 Hi WG, This email starts a 3-weeks working group last call for draft-ietf-pce-vn-association-05 [1 <https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/> ] to accommodate the upcoming draft submission deadline. Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version and it is ready for publication in your opinion. As always, review comments and nits are most welcome. The WG LC will end on Tuesday 15th March 2022. A general reminder to the WG to be more vocal during the last-call/adoption and help us unclog our queues :) Thanks, Dhruv & Julien [1] https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce