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