[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Adrian

Thank you for comments. See inline.

Adrian Farrel wrote:

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.


OK. Sounds good.

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.


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.

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.


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).

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.


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.

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.


In my opinion, the issues are relevant to both OOO and 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.

Thank you for your suggestion. I agree that it is helpful to write down the issues for bi-directional LSPs.

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.


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