draft-shiomoto-ccamp-misconnection-analysis-00.txt

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

Hi Kohei et al,

Thanks for working on this draft it is useful to have a single place to collect all of the
concerns about misconnections. As such, it is my view that this document is unlikely to
progress to RFC, but will remain as a useful "living list" of concerns to be addressed in
other drafts. It is possible, however, that we might come out of the process with some
form of BCP advising how best to avoid misconnections in deployed implementations.

The authors of the e2e recovery draft tell me that they have incorporated your concerns
into the most recent version, and it would be useful if you could review it before San
Diego and let us know whether you are satisfied. You might also like to examine the
segment protection draft to decide whether you consider this is open to misconnections.
For both drafts, it would be most useful if you could send comments to the list before San
Diego.

Another area where you were concerned about misconnection was in pre-emption. As you know,
pre-emption is currently being handled by the MPLS WG, and when (if?) it is resolved there
it will be our task to attempt to apply the MPLS-TE pre-emption solutions to GMPLS in such
as a way as to be functional and to avoid misconnections.

Specific comments on your draft are found below.

Thanks,
Adrian

====

It seems to me that your cases in 4.1 and 4.2 are actually the same case. That is, it is
not relevant that 4.1 is providing protection. What is relevant is that pre-emption of
part of a path occurs. In fact, the figures that you use to illustrate the problem are the
same, and the same pre-emptions occur. I would suggest that you combine the text under a
single discussion of pre-emption, and use a single paragraph to discuss how pre-emption
may happen in a variety of network services.

It is possible that the distinction you are trying to draw is that during restoration in a
PXC network, the lasers are already on for both pre-empting and pre-empted LSPs, while in
setup pre-emption it is only the pre-empted LSP that has an active laser. Perhaps you
could draw out this point more prominently.

Which does bring us to the question of whether the issues you raise are most significant
in PXC networks (where a signal cannot be turned off at a transit node) or whether they
are also relevant in OEO networks.

I think it would be helpful, as well, if you could write some text about the issues for
bi-directional LSPs. This seems to be a special problem not least because certain
assumptions are made about laser activation and switch programming for the reverse data
path during LSP setup.

Finally, it would be useful if your draft could point explicitly at other drafts that you
believe have misconnection issues so that your draft can act as a check-list. As we
resolve (or refute) the issues in other drafts, you can update yours to track the status.
That way we will know what work remains to be done.