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 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).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.[Editor's Note - There have been suggestions to increase this range
a little bit more, perhaps to 65024-65535]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.
The ongoing experiment code point can be maintained at the PCE WG wiki at <https://trac.tools.ietf.org/wg/pce/trac/wiki>.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
and Adrian Farrel, for their feedback and suggestions. Going through the PCEP IANA registry, following categories exist -
Essentials (already added in the draft)
MessagesObjectsTLVGood to have / simple to add
NO-PATH Object NIMetric TypeNotificationErrorClose reasonCross Registry
IRO SubobjectsXRO SubobjectsPathKey SubobjectsRSVP-TE (where ERO Subobjects is defined)The code points are kept consistent across these registriesExist Already
OF - private use for 32768-65535Not Applicable for Flags
Keeping aside some flags as experimental is not be a good ideaExperiments can always use a new experimental TLV/Object and use flags inside of itIANA RegistryGood to haveSimple to addRemarksPCEP MessagesYYEssentials (already added in the draft)PCEP ObjectsYYEssentials (already added in the draft)PCEP Message Common Header Flag FieldNAOpen Object Flag FieldNARP Object Flag FieldNANO-PATH Object NI FieldYYNO-PATH Object Flag FieldNAMETRIC Object T FieldYYMETRIC Object Flag FieldNALSPA Object Flag FieldNAIRO SubobjectsYNSVEC Object Flag FieldNANotification ObjectYYEx. NT: 224-255, NV:1-255 (*)Notification Object Flag FieldNAPCEP-ERROR Object Error Types and ValuesYYEx. ET:224-255, EV:1-255 (*)PCEP-ERROR Object Flag FieldNALOAD-BALANCING Object Flag FieldNACLOSE Object Reason FieldYYCLOSE Object Flag FieldNAPATH-KEY SubobjectsNNPATH-KEY SubobjectsYNXRO Flag FieldNAObjective FunctionYYPrivate Use already existPCEP TLV Type IndicatorsYYEssentials (already added in the draft)NO-PATH-VECTOR TLV Flag FieldNAMONITORING Object Flag FieldNAPROC-TIME Object Flag FieldNAOVERLOAD Object Flag fieldNAWG need to decide if we need to expand the scope of this document.(*) if done in this way - A new experimental Error-value/Notification-Value for an existing Error-Type/Notification-Type is not allowed, one should add a new Error-type/Notification-Type from experimental range and add the value there. Or we need to set aside experimental range for Error-value/Notification-Value for each Error-Type/Notification-Type too!