"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