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

[Dimitri.Papadimitriou@alcatel.be]

adrian - what does the term "broadcast" connection refers to in the below 
message ?

afaik in the context of MPLS-TE/GMPLS: p2p, and p2mp TE LSPs are 
considered isn'it ?





"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
31/05/2006 19:13
Please respond to "Adrian Farrel"
 
        To:     "WALTER ROTHKEGEL" <wrothkegel@lucent.com>
        cc:     <ccamp@ops.ietf.org>, "Diego Caviglia" 
<Diego.Caviglia@marconi.com>, "Dan Li <danli", "Dino Bramanti" 
<Dino.Bramanti@marconi.com>
        Subject:        Re: A nerw ID is available on the repository 
draft-caviglia-ccamp-pc-and-sc-reqs-00


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