Hi, I personally have no objection if the document is now updated to include stateful PCE extensions as well, as suggested below by Adrian. Though I would like if some more meat is added about stateful PCE, if the WG agrees -
- Section 2 Overview - Section 3.x objects -> the usage and meaning of flags etc are with respect to PCReq/PCRep only - Some more text in the new proposed section 4.3 so that it matches with similar details in section 4.1 and 4.2 - Section 5, we would need RBNF for stateful PCE messages as well as updated PCReq/PCRep for passive stateful Thanks! Dhruv From: Pce [mailto:[email protected]] On Behalf Of Adrian Farrel Sent: 25 August 2016 23:53 To: 'Jonathan Hardwick' <[email protected]>; [email protected]; [email protected] Cc: [email protected] Subject: Re: [Pce] Working group last call (including final IPR check) for draft-ietf-pce-inter-layer-ext-09 Hi Jon, I've been a passive author on this document for a few releases, so it is a good time for me to make a final review. Thanks to the other authors for their work in the meantime. I think the document is ready, but I have some suggested edits. Thanks, Adrian === Minor formatting problem (as noted by idnits) shows with a few lines too long. Curiously, these are all punctuation. --- Section 1 OLD The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. NEW The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed, and a PCE may initiate or modify services in a network by supplying new paths [I-D.ietf-pce-stateful-pce], [I-D.ietf-pce-pce-initiated-lsp]. END --- Section 1 OLD (e.g., PSC-1 and PSC-2, or VC4 and VC12) NEW (e.g., VC4 and VC12) REASON Recent discussion in TEAS suggested the PSC layers were somewhat out of fashion. Better to not list them as an example. END --- Section 1 I think that the world has moved forward since this work was started and that it now needs to give consideration to the architecture described in RFC 7926. A way to do this is... OLD The network topology formed by lower-layer LSPs and advertised as traffic engineering links (TE links) in the higher layer is called a Virtual Network Topology (VNT) [RFC5212]. NEW The network topology formed by lower-layer LSPs and advertised as traffic engineering links (TE links) in the higher layer is called a Virtual Network Topology (VNT) [RFC5212]. Discussion of other ways that network layering can be support such that connectivity in a higher layer network can be provided by LSPs in a lower layer network is provided in [RFC7926]. END --- Section 3 s/Three new/Four new/ s/SERVER-INDICATION./SERVER-INDICATION object./ --- Section 3.1 OLD The INTER-LAYER object is optional and can be used in PCReq and PCRep messages. NEW The INTER-LAYER object is optional and can be used in PCReq and PCRep messages, and also in PCRpt, PCUpd, and PCInitiate message. END --- Section 3.1 (see also 7.1) OLD INTER-LAYER Object-Class is to be assigned by IANA (recommended value=18) INTER-LAYER Object-Type is to be assigned by IANA (recommended value=1) NEW INTER-LAYER Object-Class TBD1 to be assigned by IANA. INTER-LAYER Object-Type 1 to be assigned by IANA. END --- Section 3.1 OLD When a PCReq message includes more than one request, an INTER-LAYER object is used per request. When a PCRep message includes more than one path per request that is responded to, an INTER-LAYER object is used per path. NEW When a PCReq message includes more than one request, an INTER-LAYER object is used per request. When a PCRep message includes more than one path per request that is responded to, an INTER-LAYER object is used per path. The applicability of this object to PCRpt and PCUpd messages follows as the usage of other objects on those messages as described in [I-D.ietf-pce-stateful-pce]. The applicability of this object to the PCInitiate message follows as the usage of other objects on those messages as described in [I-D.ietf-pce-pce-initiated-lsp]. END --- Section 3.2 OLD The SWITCH-LAYER object is optional on a PCRep message, where it is used with the NO-PATH object in the case of unsuccessful path computation to indicate the set of constraints that could not be satisfied. NEW The SWITCH-LAYER object is optional on a PCRep message, where it is used with the NO-PATH object in the case of unsuccessful path computation to indicate the set of constraints that could not be satisfied. The SWTCH-LAYER object may be used on a PCRpt message consistent with how properties of existing LSPs are reported on that message [I-D.ietf-pce-stateful-pce]. The SWTCH-LAYER object is not used on a PCUpd or PCInitiate message. END --- Section 3.2 (see also 7.1) OLD SWITCH-LAYER Object-Class is to be assigned by IANA (recommended value=19) SWITCH-LAYER Object-Type is to be assigned by IANA (recommended value=1) NEW SWITCH-LAYER Object-Class TBD2 to be assigned by IANA. SWITCH-LAYER Object-Type 1 to be assigned by IANA. END --- Section 3.3 OLD The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono- layer network to specify a requested adaptation capability for both ends of the LSP. In this case, it MAY be carried without INTER-LAYER Object. NEW The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono- layer network to specify a requested adaptation capability for both ends of the LSP. In this case, it MAY be carried without INTER-LAYER Object. The applicability of this object to PCRpt and PCUpd messages follows as the usage of other objects on those messages as described in [I-D.ietf-pce-stateful-pce]. The applicability of this object to the PCInitiate message follows as the usage of other objects on those messages as described in [I-D.ietf-pce-pce-initiated-lsp]. END --- Section 3.3 (see also 7.1) OLD REQ-ADAP-CAP Object-Class is to be assigned by IANA (recommended value=20) REQ-ADAP-CAP Object-Type is to be assigned by IANA (recommended value=1) NEW REQ-ADAP-CAP Object-Class TBD3 to be assigned by IANA. REQ-ADAP-CAP Object-Type 1 to be assigned by IANA. END --- Section 3.4 (see also 7.3) OLD Two new metric types are defined for the METRIC object in PCEP. Type 11 (suggested value, to be assigned by IANA): Number of adaptations on a path. Type 12 (suggested value, to be assigned by IANA): Number of layers to be involved on a path. NEW This document defines two new metric types for use in the PCEP METRIC object. IANA has assigned the value TBD5 to indicate the metric "Number of adaptations on a path." IANA has assigned the value TBD6 to indicate the metric "Number of layers to be involved on a path." See Sections 4.1 and 4.2 for a description of how these metrics are applied. END --- Section 3.5 OLD The type of SERVER-INDICATION object is to be assigned by IANA. NEW SERVER-INDICATION Object-Class TBD4 to be assigned by IANA. SERVER-INDICATION Object-Type 1 to be assigned by IANA. END --- NEW 4.3 Stateful PCE and PCE Initiated LSPs Processing for stateful PCEs is described in [I-D.ietf-pce-stateful-pce]. That document defines the PCRpt message to allow a PCC to report to a PCE an LSP that already exists in the network and to delegate control of that LSP to the PCE. When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects define in this document are used on the PCRpt to describe an LSP that is delegated to the PCE so that the PCE may process the LSP. Furthermore, [I-D.ietf-pce-stateful-pce] defines the PCUpd message to allow a PCE to modify an LSP that has been delegated to it. When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCUpd to describe the new attributes of the modified LSP. Processing for PCE initiated LSPs is described in [I-D.ietf-pce-pce-initiated-lsps]. That document defines the PCInitiate message that is used by a PCE to request a PCC to set up a new LSP. When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCInitiate to describe the attributes of the new LSP. END --- Section 6 I don't think this section will be good enough. Also I really, really think we don't need a new MIB module, but we might extend any existing modules if (and only if) they are implemented and used. OLD Manageability of inter-layer traffic engineering with PCE must address the following consideration for section 5.1. - need for a MIB module for control and monitoring - need for built-in diagnostic tools - configuration implication for the protocol NEW Implementations of this specification should provide a mechanism to configure any optional features (such as whether a PCE supports inter-layer computation, and which metrics are supported). A Management Information Base (MIB) module for modeling PCEP is described in [RFC7420]. Systems that already use a MIB module to manage their PCEP implementations might want to augment that module to provide controls and indicators for support of inter-layer features defined in this document, and to add counters of messages sent and received containing the objects defined here. However, the preferred mechanism for configuration is through a YANG model. Work has started on a YANG model for PCEP [I-D.pkd-pce-pcep-yang], and this could be enhanced as described for the MIB module, above. Additional policy configuration might be provided to allow a PCE to discriminate between the computation services offered to different PCCs. A set of monitoring tools for the PCE-based architecture are provided in [RFC5886]. Systems implementing this specification and PCE monitoring should consider defining extensions to the mechanisms defined in RFC 5886 to help monitor inter-layer path computation requests. END --- Section 7 needs a little work to help IANA. Furthermore, the values suggested here have long-since been assigned for other uses. (See also changes in Section 3.) I suggest... Section 7 ADD IANA maintains a registry called the "Path Computation Element Protocol (PCEP) Numbers". This document requests IANA to carry out actions on subregistries of that registry. END Section 7.1 OLD Four new objects: INTER-LAYER object, SWITCH-LAYER object, REQ-ADAP- CAP and SERVER-INDICATION object. NEW IANA is requested to make the following assignments from the "PCEP Objects" subregistry. Object-Class Value |Name |Object-Type |Reference -------------------+---------+-------------------------+---------------- INTER-LAYER | TBD1 | 1: Inter-layer | [This.I-D] | | 2-15: Unassigned | SWITCH-LAYER | TBD2 | 1: Switch-layer | [This.I-D] | | 2-15: Unassigned | REQ-ADAP-CAP | TBD3 | 1: Req-Adap-Cap | [This.I-D] | | 2-15: Unassigned | SERVER-INDICATION | TBD4 | 1: Server-indication | [This.I-D] | | 2-15: Unassigned | END Section 7.2 OLD IANA is requested to create a registry to manage the Flag field of the INTER-Layer object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability Description o Defining RFC Several bits are defined for the INTER-LAYER object flag fields in this document. The following values have been assigned: Bit Number Description Reference 29 T flag this document 30 M flag this document 31 I flag this document NEW IANA is requested to create a new subregistry to manage the Flag field of the INTER-Layer object called the "Inter-Layer Object Path Property Bits" registry. New bit numbers may be allocated only by an "IETF Review" action [RFC5226]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit up to a maximum of bit 31) o Capability Description o Defining RFC IANA is requested to pre-populate the registry as follows: Bit | Flag | Multi-Layer Path Property | Reference ----+------+-------------------------------+------------ 0-28| Unassigned | 29 | T | Triggered Signalling Required | [This.I-D] 30 | M | Multi-Layer Requested | [This.I-D] 31 | I | Inter-Layer Allowed | [This.I-D] END Section 7.3 OLD Two new metric types are defined in this document for the METRIC object (specified in [RFC5440]). The IANA is requested to make the following allocations from the "Metric Object T Field" registry. Value | Description | Reference ------+---------------------------------+------------ TBD5 | Number of adaptations on a path | [This.I-D] TBD6 | Number of layers on a path | [This.I-D] IANA is further requested to update the registry to show an assignment action of "IETF Consensus" as already documented in [RFC5440]. END --- Section 8 I doubt that this will be enough for the Security reviewers. But I can't think of anything better. --- Section 10.1 Add references for [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-pce-initiated-lsp]. Add reference for [RFC5226]. --- Section 10.2 Add references for [RFC5886], [RFC7420] and [RFC7926]. From: Pce [mailto:[email protected]] On Behalf Of Jonathan Hardwick Sent: 24 August 2016 12:30 To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [Pce] Working group last call (including final IPR check) for draft-ietf-pce-inter-layer-ext-09 Dear PCE working group, This email starts a working group last call for draft-ietf-pce-inter-layer-ext-09. https://datatracker.ietf.org/doc/draft-ietf-pce-inter-layer-ext/ Please read the document and reply to the PCE mailing list whether you believe this document is ready to be published, or not (including any comments on why not). The last call will end on Friday 9 September. We are also polling for knowledge of any undisclosed IPR that applies to draft-ietf-pce-inter-layer-ext-09, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving forward. If you are a document author, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The document won't progress without answers from all the authors. No IPR disclosures currently exist against this document. Many thanks Jon, JP and Julien
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
