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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 15 Sep 2006 12:52:30 +0100

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

---

From: "Diego Caviglia" <[email-masked]>
Date: Fri, 15 Sep 2006 17:09:14 +0200

Adrian,
        I'd like to thank you for having done this summary.

As an author of the ID I agree with your points.

We'll review the ID.

Regards

Diego

"Adrian Farrel" <[email-masked]>@ops.ietf.org on 15/09/2006 13.52.30

Please respond to "Adrian Farrel" <[email-masked]>

Sent by:    [email-masked]

To:    <[email-masked]>
cc:

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

Hi,

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

the process. The intention is to specify a process and develop any
necessary
protocol extensions.

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.

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

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.

the requirements draft can be answered with an applicability statement,
that

Thanks,
Adrian