Hi Ramon,
I am creating a separate thread for this! > From: Ramon Casellas [mailto:[email protected]] > 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!
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
