Re: [CCAMP] [flexi-grid] Re: New version of "Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks"

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

Thanks, Ramon, for bringing this thread to CCAMP where we can all comment on it.

> The model was more or less agreed during unofficial
> meeting during last IETF in Atlanta. Of course it is open
> to debate and can be extended or changed as we see fit.

Right. and not to be too picky, what you are saying is that a bunch of people discussed it and thought it was pretty fine and want to float it in front of the WG, but that there is no "pre-formed consensus" and that currently it is just an idea.

> The reason why it is there if I am not mistaken is two-fold:
>
> - First, as a component that, bound to a fiber, defines the 
>    working region / spectrum of the TE link, as discussed in 
>    the previous section.
>
> - Second, as the filter component that can be configured 
>   to filter a frequency slot that is then the input of the
>   matrix channel.
>
> We can change it if the agreement is not correct (for example,
> if the filter component is part of the elements that constitute
> the matrix channel). What would you propose instead? I am
> not sure I understand your suggestion. Maybe it should be
> made clear that the box with a X is just a functional element
> able to switch a frequency slot from one input port to an
> output port. On the right hand side, there is also the MUX 
> function.
>
>> In section 7.1, following model is not quite correct. 
>> What is the filter? Is it coupler, optical amplifier, or optical
>> splitter? I think there should be no any filter at both side of
>> matrix channel. 

My own view is that this whole discussion (and a significant lump of the document) is waaaaaay too far into the hardware implementation details. Material on what is, or is not, a media channel sounds like stuff Malcolm might like to find a home for in Q12/15. Discussion of filters and so forth might show up in a LMP-WDM type of document, but otherwise, I wonder why we feel the need to discuss it all in CCAMP.

Without making too light of the potential need for the material, my point is that CCAMP does control protocols. And I know you all desperately want to work out what it is legitimate to control and what not. But surely, so long as the protocol is sufficiently flexible to handle all of the potential variations, there is no need to nail stuff down further.

For example, if it turned out to be impossible (for any reason) for a frequency slot [-1, 3] to be handled by any device that could ever be invented, would it be necessary to preclude that slot in the signaling protocol? Answer: no. Obviously, it would also not be necessary to bend over backwards to support it either, but if it happens to be possible to describe a meaningless slot in the protocol, so what?

On the other hand, can a slot [-2, 2] be cross connected to [0, 4]? Can [-1, 1] be cross connected to [-2, 2] in a given direction? These are questions of some interest yet, even they remain questions about the physical devices. The devices will know whether this can be achieved and will not even attempt it. Should the protocols support these things? Yes, if they are possible. But if they are not possible, do the protocols need to forbid them or make them impossible to express? I don't think so.

There is an obsession, IMHO, with knowing every piece of information about every node and link in the network. That is *a* way. Many management systems have that approach, but they do not rely on an IGP to gather that information - they use inventory information and secret sauce. The control plane way is to know "enough" information to allow the control plane to work it out. So we need to understand the line between "everything" and "enough".  A lot of understanding that relies on knowing that each LSR will "do the right thing".

Cheers,
Adrian