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

From: Jonathan Hardwick <[email-masked]>
Date: Wed, 24 Aug 2016 11:29:57 +0000

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Aug 2016 07:51:15 +0100

Hi Jon,
 
I am not aware of any IPR that applies to this document.
 
Thanks,
Adrian
 
From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: 24 August 2016 12:30
To: [email-masked]; [email-masked]
Cc: [email-masked]
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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Aug 2016 19:22:44 +0100

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].

Dear PCE working group,

 
 
Many thanks
Jon, JP and Julien

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 26 Aug 2016 09:36:14 +0000

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-masked]] On Behalf Of Adrian Farrel
Sent: 25 August 2016 23:53
To: 'Jonathan Hardwick' <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
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

---

Section 1

OLD

---

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

---

Section 3

s/Three new/Four new/

---

Section 3.1

OLD

---

OLD

---

Section 3.1

OLD

---

Section 3.2
OLD

---

OLD

---

Section 3.3

OLD

---

OLD

---

OLD

---

Section 3.5

OLD

---

NEW

---

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

---

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

Section 7.1

OLD

Section 7.2

OLD

   o  Capability Description

   o  Defining RFC

    29            T flag        this document
    30            M flag        this document
    31            I flag        this document
NEW

   o  Capability Description

   o  Defining RFC

Section 7.3

OLD

---

Section 8

---

Section 10.1

---

Section 10.2

From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: 24 August 2016 12:30
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Pce] Working group last call (including final IPR check) for draft-ietf-pce-inter-layer-ext-09

Dear PCE working group,

Many thanks
Jon, JP and Julien