Hi, Ramon, Cyril & all, I second this solution.
Defining new C-type can also keep the current protocol and implementation untouched. But we need to loose the restriction of bandwidth object in RFC5440 first. Besides, IMHO, the solution allowing TLVs can better help the path computation process. There is no need to retrieve homogenous parameters from two different objects for PCE when computing the path. Just my view too. Thanks Qilei Wang Ramon Casellas <[email protected]> 发件人: [email protected] 2013-07-31 03:37 收件人 "Margaria, Cyril (Coriant - DE/Munich)" <[email protected]>, 抄送 "[email protected]" <[email protected]> 主题 Re: [Pce] 答复: Comments on draft-ietf-pce-gmpls-pcep-extensions-08 El 30/07/2013 18:33, Margaria, Cyril (Coriant - DE/Munich) escribió: Hi PCE WG, 3) Treat this as an errata to RFC5440 ““The BANDWIDTH of OT 1 and OT 2 object body have a fixed length of 4 bytes.”, and define new OT for GMPLS PCErs, all Rather than "Errata" :) consider it a liberal interpretation, but I guess this approach is a nice trade-off. Maybe a solution could be to define Ctypes 3 and 4 which are like 1 and 2 but allowing TLVs (generically), then define a TLV to encode GMPLS traffic parameters. The BW objects can have a 32 bit IEEE floating point encoding of the nominal rate. Current implementations support 1 and 2 with fixed size. New Ctypes can be addressed with "unknown object ctype", hopefully without strictly checking the object length. Just my view, of course R. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
