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

Re: Diverse path failure and optimality in draft-dachille-inter-area-path-protection

Hi Dimitri,

thanks for your comments, see inline.

ciao
Fabio

Dimitri.Papadimitriou@alcatel.be wrote:


hi, by discussing the proposed method there seems to be three issues that make the method questionable in terms of guarantee to deliver what it intends to deliver, its usability (the time validity of the path is not guaranteed) and its applicability in terms of objective initially targeted wrt to the network topology

1) imagine three areas decoupled computation as explained at their
respective ingress, with ARO method; how the third computation element
(tail-end) is aware of srlg's that may affect a link selected in the
head-end area

example: link 1 is selected in area 1 (head-end) with srlg 1, link 2 is
selected in in area 2 with srlg 2, and link 3 in area 3 (tail-end) with
srlg 3 and 1 (since the tail end doesn't know that srlg 1 is associated
to link 1 in addition to its association to link 3 even if it knows that
the link 1 has been selected for the ARO) the problem is that you can
not retrieve such kind of error (except but how practical is it if one
start cumulating all this information between computation points)


You´re rising this problem with SRLGs spanning non-adjacent areas.

First, I do not know if this is a common case in practical scenarios. Can other ccampers comment on that ?

Second, IMHO this case is hard to handle for _any_ distributed scheme, in lack of any exchange of info between computation points about srlg spanning multiple area.
For instance, I´m wondering if the sequential computation with RRO+XRO (as alternatve to parallel computation with ARO) can handle this scenario, or not.
Could you comment on that ?


2) resource contention, the secondary path may never be established
since the computation point as *no* capability to make any reservation
on it (except from the first segment) since by definition "disjoint" -
it simply becomes a kind of "best effort" secondary path (in the sense
use it if no other reservation are making use of these links)


In the parallel approach with ARO, during the first phase the primary LSP is establisehed (including bw reservation), while for the secondary only the path is computed.
This computation is base on the topology / load information available at the computation point, so that link without enough bw are pinned out and can not be included in the primary nor the secondary LSP.
In a successive phase, the secondary LSP is reserved along the secondary path.

What can happen is a race condition, where the bw along the secondary is available during the 1st phase, but not during the 2nd phase, since some other reservation occurred in between the two along some secondary link.
If this occurr, the secondary path can not be established, and maybe all the signaling procedure has to be repeated, for primary for secondary. (btw, let me expand in a separate mail the discussion about the case of unsuccesful computation, which was also raised by others )

First, I remark that this time window in which the race can occurr is really short, in the order of one PATH/RESV round trip time, and since hopefully you´re not going to operate your network at it´s capacity limit, the probability of failing signaling due to a race should be really small.

Second, I think that races are a well-known problem common to _all_ distributed computation/reservation schemes, i.e. not specific to parallel computation with ARO
(incidentally, I note that RSVP itself is prone to race since the path computation occurss in the downstream PATH messages, while the bw reservation is applied during the upstream RESV messages).


3) the method seems to raise additional issues when the number of potential entry point for the secondary disjoint path increases, at each step of the computation (otherwise the method wouldn't provide what it intends to deliver)

It is not clear to me what are exactly these additional issues, maybe you´d like to provide some more concrete example.
In general, my feeling is, again, that such issue might be non-specific to the parallel computation scheme, but rather common to any dstributed scheme.

However, there was a point raised by Adrian that might have some relationship to the choice of the entry-point for the secondary path.
If this is the case, you might find some interesting hints in my previous mail (posted Mon, 19 Apr 2004, http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00474.html ... sorry it´s so long :-)


As a last but important remark, let me suggest to distnguish the problems that are intrinsic to _all_ distributed diverse path computation schemes, from those that are specific to one scheme (e.g. parallel comp. with ARO). Both are important of course, but it would be beneficial to the discussion to clearly separate them in different tracks in the ml.
I´d solicit other ccamp-ers also to comment on that.