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

Dhruv Dhody <dhruv.dhody@huawei.com> Fri, 26 August 2016 09:36 UTC

Return-Path: <dhruv.dhody@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF83612D097; Fri, 26 Aug 2016 02:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.768
X-Spam-Level:
X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY3RJCod_JTZ; Fri, 26 Aug 2016 02:36:32 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DAE012B041; Fri, 26 Aug 2016 02:36:31 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CVC06153; Fri, 26 Aug 2016 09:36:27 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Aug 2016 10:36:25 +0100
Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0235.001; Fri, 26 Aug 2016 15:06:15 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Jonathan Hardwick' <Jonathan.Hardwick@metaswitch.com>, "pce@ietf.org" <pce@ietf.org>, "draft-ietf-pce-inter-layer-ext@ietf.org" <draft-ietf-pce-inter-layer-ext@ietf.org>
Thread-Topic: [Pce] Working group last call (including final IPR check) for draft-ietf-pce-inter-layer-ext-09
Thread-Index: AdH9+dMM1WrpiPFnR8a0sWnvvIg/7wA1b9wAAB+7btA=
Date: Fri, 26 Aug 2016 09:36:14 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8C945919@blreml501-mbx>
References: <BY2PR0201MB1910CD74213C7FC3E287B4D784EA0@BY2PR0201MB1910.namprd02.prod.outlook.com> <015401d1fefd$b1bab7c0$15302740$@olddog.co.uk>
In-Reply-To: <015401d1fefd$b1bab7c0$15302740$@olddog.co.uk>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.244.252]
Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C945919blreml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57C00D9D.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: fb2b43bae1c4b6d1330a0e7c541ab465
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/ItshVlQl1L_nvlbK2mC7uhkVQuM>
Cc: "pce-chairs@ietf.org" <pce-chairs@ietf.org>
Subject: Re: [Pce] Working group last call (including final IPR check) for draft-ietf-pce-inter-layer-ext-09
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Aug 2016 09:36:37 -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:pce-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: 25 August 2016 23:53
To: 'Jonathan Hardwick' <Jonathan.Hardwick@metaswitch.com>; pce@ietf.org; draft-ietf-pce-inter-layer-ext@ietf.org
Cc: pce-chairs@ietf.org
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:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 24 August 2016 12:30
To: pce@ietf.org<mailto:pce@ietf.org>; draft-ietf-pce-inter-layer-ext@ietf.org<mailto:draft-ietf-pce-inter-layer-ext@ietf.org>
Cc: pce-chairs@ietf.org<mailto:pce-chairs@ietf.org>
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