Re: A nerw ID is available on the repository draft-caviglia-ccamp-pc-and-sc-reqs-00

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Walter,

Thanks for your thoughts.

May I restate them to make sure that I understand?

> While I think these requirements are real, I can not imagine that they
> can be solved by some protocol extensions.

If I am interpretting you correctly, you are saying that you agree with the 
requirements. This means that *if* they can be solved, you would be quite 
pleased. And even if they could only be solved in certain control 
situations, you would also think that a good thing.

On the other hand, you are skeptical that a solution can be developed. 
Presumably, this means that you would not want to spend your time attempting 
to develop one, or see the WG expend much bandwidth on trying to find a way 
to meet the requirements. But I don't suppose you would object if the 
authors of this I-D spent their own time trying to hatch a solution and then 
brought it to the working group for discussion.

> One reason is, as it is stated in the I_D, that "ownership by the 
> Management
> and Control Planes is strictly an implementation issue", which we can not
> solve by a protocol alone.

Hmmm. Yeah I guess it could be a problem if a device determined that it 
would not allow resources to be exchanged between the two planes. Handling 
(or, more precisely, not handling) NEs that do not support these funcitons 
certainly has to be discussed. I suppose there are two situations:
1. As you describe, the LSP cannot be shifted. I.e. the LSR understands
 the request but is unable or unwilling to comply.
2. The LSR does not understand the request. I.e. it has not been
 upgraded to handle the protocol solution.

I think this is actually business as usual for protocol work, isn't it?

> Secondly, the MP and CP typically store additional data associated with 
> the
> connection, which is implementation specific, but needs also appropriate
> conversion, or the conversion must at least ensure data integrity.

I'd be intrigued to know what additional informaiton a standard GMPLS 
control plane is going to store over and above what is signaled by the 
protocol. So the problem you describe is lopsided - if the MP and CP are 
capable of storing the additional information then I think there is no issue 
(and presumably everything is the same implementation-specific stuff). But 
if there are differences in implmentations in the CP, then they must be 
running some common set of protocol extensions and it is this that needs to 
be converted to/from the MP.

Note that if the MP offers the ability to configure things on an NE that 
cannot be carried in signaling then those things cannot bve carried in 
signaling, period. That is, you cannot consider provisioning an LSP in the 
CP at all if you need to carry this information. Fortunately, we are not 
having a discussion on the relative merits of using a control plane - the 
situation we are examining is one where the operator (the customer!) has 
decided to move ownership of an LSP between planes, and wants to know how to 
do it. That means that the operator has already accepted that the LSP can be 
managed by both planes and wishes to make the transfer without turning the 
service down.

> Finally, need to look, what is convertible at all. E.g., the MP may have
> implemented certain broadcast or multicast connections, or special 
> protection
> schemes, which are not (yet) supported by the CP.

Yes, there is the possiblity that certain services in the MP cannot be 
achieved in the CP (although it would be interesting to discuss which, 
because if there is a need, the control plane is surely in need of 
enhancement). So you are right, there may be some LSPs that cannot be 
migrated in this way. But what about those that can? Do you think we should 
at least consider these requirements for those LSPs that can be migrated?

Many thanks,
Adrian