Re: [Pce] Experimental Codepoints allocation in PCEP registry

[Ramon Casellas <[e-mail]>]

On 16/06/2016 7:25, Dhruv Dhody wrote:
> Hi Adrian,
>
>> How would you all feel about 8? (My instinct is to push for 4, but I can
>> pre-emptively compromise :-)
> I can work with 8 :)

Seems quite reasonable to me :) now, let's say the "message" was the 
first (easy?) one. Objects and TLVs? Although I don't have a strong 
opinion, my two cents:

If I had to suggest something, in the experiments I have been involved 
with, procedures "at the message level" are rarely modified and not 
significantly extended. Most of the time we can do with 2-3 experimental 
messages ("PCEPTopologyUpdate, PCEPAlarm, PCEPCrossConnect", etc.) which 
is inline with the above.  Most of the time we try to extend a given 
message with either objects, TLVs is where most of the extensions go 
(e.g. to add "optical specific information", and I would rather use a 
"notification type wrapper for topology" instead of "PCEPTopologyUpdate")

- Objects 224 - 255 , to me it is ok. Shifting a bit around would either 
be 192 or 240, which at first sight seems too many or too few.

- TLVs 65280-65535 IMHO, this is slightly "tight" (erring on the side of 
caution, we never used that many)  other alternatives 63488, 64512 and 
65024 (I may tend to suggest these values for bit masking rather than 
65000- but both are perfectly ok

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?

thank you and best regards
R.