Hi Ramon, See inline...
> -----Original Message----- > From: Ramon Casellas [mailto:[email protected]] > Sent: 16 June 2016 11:27 > To: Dhruv Dhody <[email protected]>; [email protected]; > [email protected] > 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. > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
