Experimental Codepoint Allocation for Path Computation Element communication
Protocol (PCEP)Huawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560066Indiadhruv.ietf@gmail.comLancaster UniversityUKd.king@lancaster.ac.uk
Routing
PCE Working Group
IANA assigns values to the Path Computation Element (PCE) communication
Protocol (PCEP) parameters (messages,
objects, TLVs). IANA established a new top-level registry to contain all PCEP
codepoints and sub-registries. The allocation policy for each new
registry is by IETF Consensus.This document seeks to mark some codepoints for experimental usage
of PCEP. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .The Path Computation Element communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.In section 9 of , IANA assigns values to
the PCEP protocol parameters (messages, objects, TLVs). IANA established
a new top-level registry to contain all PCEP codepoints and sub-registries.
The allocation policy for each new registry is by IETF Consensus as
described in . Specifically, new assignments
are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective
assignments from appropriate persons (e.g., a relevant Working Group
if one exists). Early
allocation provides some latitude for allocation of these
code points, but is reserved
for features that are considered appropriately stable.With some recent advancement, there is an enhanced need to
experiment with PCEP. It is often necessary
to use some sort of number or constant in order to actually
test or experiment with the new function, even when testing in a
closed environment. In order to run experiment, it is important that
the value won't collide not only with existing codepoints but any
future allocation. This document thus set apart some codepoints
in PCEP registry and subregistries for experimental usage. Some codepoints are requested to be set aside for experimentation
with new PCEP messages. The suggested range is 246-255.Some codepoints are requested to be set aside for experimentation
with new PCEP objects. The suggested range is 224-255.Some codepoints are requested to be set aside for experimentation
with new PCEP TLVs. The suggested range is 65280-65535.A PCEP implementation that receives an experimental PCEP message, that it does not recognize, would react as per section 6.9 of
by sending a PCErr message with Error-value=2 (capability not supported).
A PCE that does not recognize an experimental PCEP object, MUST reject the
entire PCEP message and MUST send a PCE error message with Error-
Type="Unknown Object" or "Not supported object", defined as per
.As per section 7.1 of , unknown experimental PCEP TLV would be ignored.IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
at <http://www.iana.org/assignments/pcep>.Within this registry IANA maintains a sub-registry for PCEP
Messages (see PCEP Messages at <http://www.iana.org/assignments/pcep>).Upon approval of this document, IANA is requested to make the
following allocations: Within this registry IANA maintains a sub-registry for PCEP
Objects (see PCEP Objects at <http://www.iana.org/assignments/pcep>).Upon approval of this document, IANA is requested to make the following allocations: Within this registry IANA maintains a sub-registry for PCEP
TLVs (see PCEP TLV Type Indicators at <http://www.iana.org/assignments/pcep>).Upon approval of this document, IANA is requested to make the
following allocations: The allocation policy for the IANA request in is "Experimental".
As per , IANA does not record specific assignments for any particular use for this policy.As the experiment/standard progress and an early IANA allocation or RFC publication happens, the IANA defined codepoints are used
and experimental code points are freed up.This document does not introduce any new security considerations to
the existing protocol. Refer to for
further details of the specific security measures. The authors would like to thank Ramon Casellas, Jeff Tantsura,
Adrian Farrel, Jonathan Hardwick, Julien Mueric, Lou Berger,
Michael Shroff, and Andrew Dolganow for their feedback and suggestions. Based on the feedback from the WG, it was decided to focus
only on the essentials in the scope of this documents. For others,
Experiments can use a new experimental TLV/Object instead.