Re: [Pce] Working group last call (including final IPR check) for draft-ietf-pce-inter-layer-ext-09

["Adrian Farrel" <[e-mail]>]

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:[e-mail]] On Behalf Of Jonathan Hardwick
Sent: 24 August 2016 12:30
To: [e-mail]; [e-mail]
Cc: [e-mail]
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