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(_dot_)meuric(_at_)orange(_dot_)com
[mailto:julien(_dot_)meuric(_at_)orange(_dot_)com]
Sent: mercoledì 9 settembre 2015 10:53
To: Daniele Ceccarelli; adrian(_at_)olddog(_dot_)co(_dot_)uk; 'Adrian
Farrel'; '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: [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(_dot_)ceccarelli(_at_)ericsson(_dot_)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(_at_)olddog(_dot_)co(_dot_)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(_at_)ietf(_dot_)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.