Hi Robert,
Thanks for the careful review and your comments.
I pretty much agree with Adrian's reply but I think explicitly having some
backward compatibility text in the draft could be helpful.
Adrian, authors, I'd suggest changing section 5 from "Manageability
Considerations" to "Backward Compatibility and Manageability Considerations"
adding to the existing text backward compatibility considerations against
legacy GMPLS and legacy NMS (mostly what you've already written below).
WRT the legacy NMS I don't think it is a reasonable scenario, since before
operating the nodes with a GMPLS implementing this draft, the node needs to be
configured and the NMS must be flexi-grid compatible.
Robert, would this address your concerns?
Many thanks
Daniele
-----Original Message-----
From: Adrian Farrel [mailto:afarrel(_at_)juniper(_dot_)net]
Sent: giovedì 3 settembre 2015 09:11
To: 'Robert Sparks';
draft-ietf-ccamp-flexigrid-lambda-label(_at_)ietf(_dot_)org;
ccamp(_at_)ietf(_dot_)org; 'General Area Review Team';
ietf(_at_)ietf(_dot_)org
Subject: RE: Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04
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