Re: [Pce] Experimental Codepoints allocation in PCEP registry

[Dhruv Dhody <[e-mail]>]

Hi Ramon, 

See inline...

> -----Original Message-----
> From: Ramon Casellas [mailto:[e-mail]]
> Sent: 16 June 2016 11:27
> To: Dhruv Dhody <[e-mail]>; [e-mail];
> [e-mail]
> Subject: Re: [Pce] Experimental Codepoints allocation in PCEP registry
> 
> 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.
> 
[Dhruv] Assuming we have messages and objects out of our way with -  
PCEP Messages - 246-255
PCEP Objects - 224-255

> - 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
> 
[Dhruv] Yes, there are experiments that can require quite a few TLVs at disposal, I felt that setting aside 255 (65280-65535) was appropriate. 
To be extra safe and moving it to 65024 would be ok too if that is what the WG desire. 

> 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] I will create a separate thread for this for easier tracking. 

Regards,
Dhruv


> thank you and best regards
> R.
>