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

[Kohei Shiomoto <[e-mail]>]

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