Huawei Technologies

Divyashree Techno Park, Whitefield Bangalore Karnataka 560066 India dhruv.ietf@gmail.com

Lancaster University

UK d.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) Messages Objects TLV Good to have / simple to add NO-PATH Object NI Metric Type Notification Error Close reason Cross Registry IRO Subobjects XRO Subobjects PathKey Subobjects RSVP-TE (where ERO Subobjects is defined) The code points are kept consistent across these registries Exist Already OF - private use for 32768-65535 Not Applicable for Flags Keeping aside some flags as experimental is not be a good idea Experiments can always use a new experimental TLV/Object and use flags inside of it IANA Registry Good to have Simple to add Remarks PCEP MessagesYYEssentials (already added in the draft) PCEP ObjectsYYEssentials (already added in the draft) PCEP Message Common Header Flag FieldNA Open Object Flag FieldNA RP Object Flag FieldNA NO-PATH Object NI FieldYY NO-PATH Object Flag FieldNA METRIC Object T FieldYY METRIC Object Flag FieldNA LSPA Object Flag FieldNA IRO SubobjectsYN SVEC Object Flag FieldNA Notification ObjectYYEx. NT: 224-255, NV:1-255 (*) Notification Object Flag FieldNA PCEP-ERROR Object Error Types and ValuesYYEx. ET:224-255, EV:1-255 (*) PCEP-ERROR Object Flag FieldNA LOAD-BALANCING Object Flag FieldNA CLOSE Object Reason FieldYY CLOSE Object Flag FieldNA PATH-KEY SubobjectsNN PATH-KEY SubobjectsYN XRO Flag FieldNA Objective FunctionYYPrivate Use already exist PCEP TLV Type IndicatorsYYEssentials (already added in the draft) NO-PATH-VECTOR TLV Flag FieldNA MONITORING Object Flag FieldNA PROC-TIME Object Flag FieldNA OVERLOAD Object Flag fieldNA WG 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!