Re: [Gen-art] Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04

[Daniele Ceccarelli <[e-mail]>]

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:[e-mail]]
> Sent: giovedì 3 settembre 2015 09:11
> To: 'Robert Sparks'; [e-mail];
> [e-mail]; 'General Area Review Team'; [e-mail]
> 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