Attempting consensus on draft-caviglia-ccamp-pc-and-sc-reqs-03.txt

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

Hi,

We had a lively debate, and I promised to try to summarise the points to see
if we have some form of consensus.

draft-caviglia-ccamp-pc-and-sc-reqs-03.txt describes a problem space where
the authors say it is desirable to be able to transfer control of an LSP
between the management plane and a GMPLS control plane. They support this
claim with various scenarios. They then develop a series of requirements on
the process. The intention is to specify a process and develop any necessary
protocol extensions.

Re-reading the thread, I think I see the following points:

1. General agreement that transfer of control from the management plane to
the control plane is a realistic scenario as a GMPLS control plane is
introduced into an existing network where LSPs have been established using
the management plane.

2. Some disagreement about whether point 1 needs to be performed
dynamically, but nevertheless agreement that some operators may wish to make
the transfer hitlessly (i.e. without a maintenance period) and in a network
without sufficient spare capacity to establish a parallel LSP.

3. Considerable disagreement about some of the scenarios (documented and
raised on the mailing list) for the transfer of control from the control
plane to the management plane.

4. Some understanding that if transfer from the management plane to the
control plane is supported, there will be a desire to back-out the process,
for example if the operator is not happy with the result.

5. Some debate over whether either of the transfers (but particularly the
transfer from control plane to management plane) would result in any
extensions to the protocols.

6. Concern that handling failure events, where control of the LSP ends up in
some mixed mode, could be very messy.


My conclusions, therefore, are:

A. There is consensus to work on transfer from the management plane to the
control plane.

B. There is enough interest to justify work on the transfer from the control
plane to the management plane, but this should be scoped as a back-out
procedure.

C. The requirements should initially state the functional requirements and
should not assume that changes to the protocols are necessary. That is, if
the requirements draft can be answered with an applicability statement, that
would be good all round. Later section of the draft can state current
protocol behavior, and point out any gaps that need to be filled.

D. The requirements draft must cover the requirements for failure cases in
good detail


We should encourage the authors to revise their draft along these lines at
which time the working group may be more likely to find itself in full
consensus.

Thanks,
Adrian