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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Jul 2004 12:13:18 +0100

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.

---

From: Kohei Shiomoto <[email-masked]>
Date: Fri, 23 Jul 2004 21:50:00 +0900

Hi Adrian

Thank you for comments. See inline.

>form of BCP advising how best to avoid misconnections in deployed implementations.
OK. Sounds good.

>For both drafts, it would be most useful if you could send comments to the list before San
OK. I will review the recent version of both drafts and send comments if 
any.

As a matter of fact, I had a chance to review the recent version e2e 
recovery draft a few days ago. I recognized that the issues are 
carefully addressed in Section 8.3 and Section 10. What we would like to 
discuss in the missconnection draft is to find the common solution 
applicable to different misconnection scenario if any. If the solution 
presented in the e2e recovery draft is applicable to other scenario, it 
is fine.

>may happen in a variety of network services.
Cases in 4.1 and 4.2 look similar to each other. The slight difference 
is the existence of refresh messages for the pre-empting LSP. In 
shared-mesh restoration case (Section 4.1), the pre-empting LSP is 
provisioned but not yet cross-connected before the preemption takes 
place. We need to be careful about distinction between refhreshing and 
activating Path messages. On the other hand, in the case of Section 4.2, 
the pre-empting LSP is not provisioned before the preemption takes 
place. So we don't have to care about the refreshing messages in 
developing the mechanism to avoid misconnection.

However I agree that sections 4.1 and 4.2 can be merged since they have 
common parts (preemption).

>could draw out this point more prominently.
As you pointed out, it is more likely to have misconnection in OOO type 
PXC case, depending on the switch mechanism used in the node (See also 
the last paragraph of Section 5). The solution might be different for 
OOO case and OEO case.

>are also relevant in OEO networks.
In my opinion, the issues are relevant to both OOO and OEO networks.

>assumptions are made about laser activation and switch programming for the reverse data
Thank you for your suggestion. I agree that it is helpful to write down 
the issues for bi-directional LSPs.

>That way we will know what work remains to be done.
OK, I would be happy to revise the draft if there are misconnection 
issues in other scenario.

Thanks

-- 
Kohei Shiomoto
NTT Network Service Systems Laboratories