RE: Re-Updated Draft Liaison to Q6/15

["O'Connor, Don" <[e-mail]>]

Adrian, Malcolm

Malcolm's email and Adrian's reply do not address the key issue of how
the link impairments are measured or estimated. It is up to ITU SG 15 Q6
to determine how this should be accomplished such that wavelength
routing and assignment with optical impairments produces a satisfactory
result for service providers. ITU SG 15 has responsibility for the
optical channel data plane not CCAMP. 

ITU SG 15 Q6 needs to specify what information the Path Computation
Elements requires to adequately perform the computation, and how it is
measured or acquired including the role of ROADM /OXC. After ITU SG 15
Q6 specifies these details (note that it may be necessary for ITU SG 15
to generate one or more new standards or standard amendments), then
CCAMP can specify what protocols to use and how to encode the
information.

With respect to the liaison, Adrian indicated below,

" I'm open to suggestions of text."

I proposed an updated version of the liaison yesterday. I suggest that
we either use this version or somebody propose an update to what I
proposed

Regards

Don



-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Wednesday, March 11, 2009 9:22 AM
To: Malcolm Betts; O'Connor, Don; [e-mail]
Subject: Re: Re-Updated Draft Liaison to Q6/15

Thanks Malcolm.
Helpful.

> Looking at the comments from Don and Dan I think we should take
> a step back and think about the requirements that the protocol
> extensions are intended to address

Sure

> I think we can all agree that we must be able to report link
> impairments and the encoding we use should accommodate
> the parameters currently defined by Q6 and should be
> extensible to accommodate any parameters that are defined
> at a later date.

That is true.
And that (I was hoping) is the bulk of the work to be done with Q6's
help.

> Now to the more contentious issues:
>
> - How frequently do we expect the impairment parameters to
>   change, is it in the order of mSec, Seconds, minutes, hours,
>   days.  I suggest that once it is beyond seconds the actual
>   frequency becomes a "don't care".

You missed "never".

>From a protocol standpoint there are only three categories:
- never
- within the bounds of a routing protocol to advertise
- too fast for a routing protocol to advertise.

Certainly Q6 can help us identify if the third case applies. (I had
assumed 
not since current networks use manual configuration.)

> - Does the protocol need to activate/deactivate measurements
>   on an in service link.  If so what types of parameters would
>   need to be specified for these measurements.

I have not heard anyone asking for this (perhaps I am not listening?).
This seems like a whole different kettle of ball-games akin to running 
before we can walk.

> My assumption is that if we define an extensible method for
> reporting link impairment parameters then we can use the
> same message to report any link impairments independent
> of how they are provided (provisioned, measured at installation
> time, measured in service...).

Right.
Yes, isn't this where we started?
What we need from Q6 is help to understand how to encode each of the 
parameters, and what the ranges are for each parameter.

> I suggest that we phrase the liaison to get input from Q6
> to help us define the requirements for these last two points.

I'm open to suggesitons of text.

Adrian