ietf
[Top] [All Lists]

RE: Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04

2015-09-09 02:41:52
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
To: Daniele Ceccarelli; '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: Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04

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