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

From: Dhruv Dhody <[email-masked]>
Date: Thu, 16 Jun 2016 16:29:26 +0000

Hi Ramon,

I am creating a separate thread for this!

> From: Ramon Casellas [mailto:[email-masked]]

> 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!