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]; [email protected]
Cc: [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
