Re: Re-Updated Draft Liaison to Q6/15

["Adrian Farrel" <[e-mail]>]

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