RE: Re-Updated Draft Liaison to Q6/15

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

Adrian

The draft liaison text below does not ask Q6/15's views on how the
optical link impairment data should be acquired such that the wavelength
routing assignment achieves satisfactory results. Some potential options
are

1) ROADM / OXC measure impairments in service - At present there are no
ITU SG 15 standards for this

2) ROADM / OXC estimate link impairment based on measuring some link
parameters - At present there are no ITU SG 15 standards for this

3) Link impairments are measured out of service with some test equipment
- then you do not need any CCAMP ROADM protocols - the measurement
results can be directly exported from the test equipment to the PCE

4) Link impairments are estimated without making any measurements - we
do not need any CCAMP ROADM protocols

The draft text in the liaison below appears to assume that ITU SG 15
already has standards in place to support control plane based wavelength
routing and assignment based on optical impairments, and all that is
necessary is for SG 15 Q6 to provide CCAMP with some guidance on how to
use these standards. I do not this is the case, particularly for the
case of 1) or 2) above. 

Let me make an analogy. Today there are no IETF MPLS OAM standards for
PM measurement. It would not be good for ITU to go off and generate some
standards that would require MPLS LSR to perform some PM measurements.

To move the process forward, I will propose the following update to the
draft liaison text below

"We would appreciate Q6/15's view on the following issues:
- What optical link impairments are suitable for consideration in this
  type of network,
- How should these impairments be measured, estimated, or otherwise
determined
- In addition to optical link impairments, should other impairments be
considered such as those introduced by ROADM / OXC, Optical Amplifiers,
etc 
- What rules should we use for these impairments to achieve
  a reasonable approximation of how they are accumulated
  along a path?
  That is, CCAMP is looking for the rules by which the end-
  to-end impairments of a path may be determined from a
  knowledge of parameters of the path and impairments on
  the path segments.
- What are the generic encodings and ranges of values for
  the impairment parameters?
- Which existing Recommendations can be applied
- Will it be necessary for ITU SG 15 Q6 to generate any new
Recommendations or Amendments to existing Recommendations to support
this application?"

Regards

Don


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

Don,

You will see from the liaison sent that we have said...

"It is not within the scope of CCAMP to determine how impairments are
gathered."

and

"We would appreciate Q6/15's view on the following issues:
- What impairments are suitable for consideration in this
  type of network, and which Recommendations should we use
  as references?
- What rules should we use for these impairments to achieve
  a reasonable approximation of how they are accumulated
  along a path?
  That is, CCAMP is looking for the rules by which the end-
  to-end impairments of a path may be determined from a
  knowledge of parameters of the path and impairments on
  the path segments.
- What are the generic encodings and ranges of values for
  the impairment parameters?"

I hope you feel that this defers suitably to Q6/15.

If it does not, I feel sure that they will tell us their feelings.

Thanks,
Adrian


----- Original Message ----- 
From: "O'Connor, Don" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; "Malcolm Betts" 
<[e-mail]>; <[e-mail]>
Sent: Wednesday, March 11, 2009 10:17 PM
Subject: RE: Re-Updated Draft Liaison to Q6/15


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