Hi Robert, Thanks for reading. > Summary: Ready for publication as a Proposed Standard Excellent diagnosis :-) > One thing I'd like to check, and I suspect this pokes at a conversation > that has already happened (as hinted in the acknowledgements section): > > The discussion of managements systems having to deal with a 64 bit > wavelength label caught my eye. This is an RFC3471 section 3.2.1.1 label > isn't it? That document shows wavelength labels as 32 bit things. Has > something updated 3471 to say to expect a multiple of 32 bits, and not > 32 bits specifically? If not, maybe this document would be a good place > to do so explicitly, rather than what appears to be fiat at the moment? Yeah, 6205 updates 3471 (as noted in this I-D), but still only makes a 32 bit lambda label. But 3.2 of 3471 makes clear that a label is of variable length according to the type. And also that the type is supposed to be known a priori (since otherwise you would go crazy) by both ends of a link. But an implementation expecting a 32 bit lambda label would not barf ungracefully because the first 32 bits follow the format of 6205. It would look at them and not recognise the grid type (new value from IANA) and so give up on the whole message. And this is good because if you don't support flexigrid labels you simply can't process any of the related signaling. Thus, we think that the only thing that needs fixing (external to the implementation that has to support flexigrid labels) is the management system that might be inspecting LSPs within the network. > micro-nit: at the end of the introduction "in that regard" suggests the > document updates the work of the ITU-T in some other regard? I suggest > simple deleting the phrase. Micro-ack. Cheers, Adrian