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

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@orange.com [mailto:julien.meuric@orange.com]
> Sent: mercoledì 9 settembre 2015 10:53
> To: Daniele Ceccarelli; adrian@olddog.co.uk; 'Adrian Farrel'; 'Robert Sparks';
> draft-ietf-ccamp-flexigrid-lambda-label@ietf.org; ccamp@ietf.org; 'General
> Area Review Team'; ietf@ietf.org
> 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@ericsson.com:
> > 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@olddog.co.uk]
> >> 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@ietf.org
> > 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.