[Pce] Experimental Codepoint for all registries (was: RE: Experimental Codepoints allocation in PCEP registry)

[Dhruv Dhody <[e-mail]>]

Hi Ramon,



I am creating a separate thread for this!



> From: Ramon Casellas [mailto:[e-mail]]

> One final comment. If we want (do we? do we need to?) to cover everything,

> we may need to consider (just thinking out loud):

>

> - OF Codes  -- we use this a lot, almost none of the std. algorithms address

> e.g. wavelength aspects, etc.

>

> - Error types, error values, -- we use this to convey "failed because there

> were no optical regenerators available"

>

> - Notification types, notification values -- see above

>

> - ?RO subobjects (this is tricky, it is not only PCEP)  -- we have used

> "transceiver subobject", "regenerator subobject"

>

> - ... other?

>



[Dhruv] We wanted to take up this discussion, once we have the message/object/TLV out of our way.



Going through the PCEP IANA registry, I would divide this as -



l  Essentials (already added in the draft)

n  Messages

n  Objects

n  TLV

l  Good to have  / simple to add

n  NO-PATH Object NI

n  Metric Type

n  Notification

n  Error

n  Close reason

l  Cross Registry

n  IRO Subobjects

n  XRO Subobjects

n  PathKey Subobjects

n  Need to worry about RSVP-TE  (where ERO is defined)

n  The code points are kept consistent across these registries

n  Making this harder to add (as pointed out by Ramon too)

l  Exist Already

n  OF

u  private use for 32768-65535

l  Not Applicable for Flags

n  Keeping aside some flags as experimental is not be a good idea

n  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 Messages


Y


Y


Essentials (already added in the draft)


PCEP Objects


Y


Y


Essentials (already added in the draft)


PCEP Message Common Header Flag Field








NA


Open Object Flag Field








NA


RP Object Flag Field








NA


NO-PATH Object NI Field


Y


Y


NO-PATH Object Flag Field








NA


METRIC Object T Field


Y


Y


METRIC Object Flag Field








NA


LSPA Object Flag Field








NA


IRO Subobjects


Y


N


SVEC Object Flag Field








NA


Notification Object


Y


Y


Ex. NT: 224-255, NV:1-255 (*)


Notification Object Flag Field








NA


PCEP-ERROR Object Error Types and Values


Y


Y


Ex. ET:224-255, EV:1-255 (*)


PCEP-ERROR Object Flag Field








NA


LOAD-BALANCING Object Flag Field








NA


CLOSE Object Reason Field


Y


Y


CLOSE Object Flag Field








NA


PATH-KEY Subobjects


N


N


XRO Subobjects


Y


N


XRO Flag Field








NA


Objective Function


Y


Y


Private Use already exist


PCEP TLV Type Indicators


Y


Y


Essentials (already added in the draft)


NO-PATH-VECTOR TLV Flag Field








NA


MONITORING Object Flag Field








NA


PROC-TIME Object Flag Field








NA


OVERLOAD Object Flag field








NA






Now as a WG we need to decide if we should expand the scope? And to what extent?



Regards,

Dhruv





(*) 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!