Hi Julien, Thanks for providing and operator point of view and for proving I'm wrong :) We have one more reason to update the draft with the backward compatibility statements then. Thanks a lot, Daniele > -----Original Message----- > From: julien.meuric@xxxxxxxxxx [mailto:julien.meuric@xxxxxxxxxx] > Sent: mercoledì 9 settembre 2015 10:53 > To: Daniele Ceccarelli; adrian@xxxxxxxxxxxx; 'Adrian Farrel'; 'Robert Sparks'; > draft-ietf-ccamp-flexigrid-lambda-label@xxxxxxxx; ccamp@xxxxxxxx; 'General > Area Review Team'; ietf@xxxxxxxx > Subject: Re: [CCAMP] Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda- > label-04 > > Ciao Daniele. > > SP's hat on, I need to disagree with you there. > > What Adrian proposes allows me to add new pieces of equipment to address > traffic needs, without waiting for an NMS release supporting 100% of the > feature I use. In this situation, I can choose between upgrading or waiting for > the full package alignment: it remains my call, on a case by case basis. The > wording also emphasizes the generalized beauty of GMPLS: > new label encodings should not prevent the management of other protocol > aspects ("be liberal in what you accept...). > > What you suggest would prohibit that scenario, i.e., I need wait for fully- > featured NMS, whatever the network is capable of. This is sometimes not > acceptable: service needs prevail on fully detailed management, the NMS > should not be a network limitation. The current example, where label > resolution could rely on a (temporary?) external tool, makes it even more > realistic. > > Regards, > > Julien > > > Sep. 09, 2015 - daniele.ceccarelli@xxxxxxxxxxxx: > > Hi Adrian, > > > > I tend disagree with this statement: > > > > "My contention is that it is quite likely that someone would try to use a > legacy NMS to manage a new flexigrid network since "it is all just GMPLS". > And it is not an unreasonable assumption to be able to do this if some fields > (for example, label) can be displayed as opaque quantities." > > > > I'm not sure an operator would be happy to see 96 channels called > lambda1, lambda2,..., lambda 96 from his NMS while the network is flexi > grid. > > We'll have to face these issues when we'll be speaking about YANG models > for flexi grid but for the time being let's be on the safe side and address the > compatibility issue as you're suggesting. > > > > Cheers, > > Daniele > > > >> -----Original Message----- > >> From: Adrian Farrel [mailto:adrian@xxxxxxxxxxxx] > >> Sent: martedì 8 settembre 2015 18:02 > >> > >> Hi Daniele, > >> > >>> 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). > >> > >> I can work on this. > >> > >>> 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. > >> > >> But wait! This is exactly the point. > >> Suppose there is an NMS that is inspecting an LSP at a transit node. > >> That NMS does not need to be flexigrid compatible to read the details > >> of the LSP at that transit node. > >> However, it *does* need to have some capabilities in order to not > >> barf when it gets the response from the LSR. > >> The first thing is to handle a 64 bit label as an opaque string. > >> The advanced thing is to be able to parse out the 64 bits into the > >> relevant fields. > >> > >> Indeed, to request the setup of a flexigrid LSP does not require a > >> flexigrid compatible NMS since it is possible to simply request a > >> path and bandwidth (or not even request a path). > >> > >> My contention is that it is quite likely that someone would try to > >> use a legacy NMS to manage a new flexigrid network since "it is all > >> just GMPLS". And it is not an unreasonable assumption to be able to > >> do this if some fields (for example, label) can be displayed as opaque > quantities. > >> > >> Now, if you are talking about an EMS, I completely agree. > >> > >> Cheers, > >> Adrian > >> > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ccamp > > > > ______________________________________________________________ > ___________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you.