[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 - see in-line

ricciato wrote:

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.

yes, because it's another flavour of the trap problem (the proposal solves the single area trap issue and not the multi-area one and it is not a criticism but a way to determine the exact coverage of the method)

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.

any signaling that carries srlg explicit information is rather impractical and i don't think there is currently another way to solve this issue (in a distributed way) other than performing lookups from the link_id's on locally available information bases

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 ?

see above - in brief is to know what the proposal can cover and does not cover and in the latter case whether it is capable to detect it

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.

yes, it is a parallel multi-hop computation with a sequential signaling (i don't have any doubt about this)

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 )

ok -

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.

at least this raises the issue of applicability (this will be greatly depending on the arrival time, the amount of unreserved bandwidth and the (diverse) connectivity degree of each abr)

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

but it becomes more problematic since the computation has no control at
all over the "diverse segment" it has computed (at the end the issue is
to make the scheme working it imposes operational procedures) this does not mean that other mechanisms (existing and to come have full control)

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. 

if at each computation point the number of alternatives increases, i
have some difficulties to understand how this mechanism works, either
pruning of these alternatives is performed (so global optimality can
never be achieved) or you're going to maintain and extend them until
reaching the end-point (is that really feasible ?)

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. 

would it be possible to tell us instead which are the conditions in
which the scheme works rather than raising the flag of "non-specific to
the parallel computation scheme but common to any distributed scheme"
since afaik this scheme is also distributed

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.

there are issues intrisic to the method and issues that applies to distributed method that applies also to this method and i agree that the proposed method won't solve them all - but it is imho part of the discussion to exactly know what the method covers, can potentially cover and not cover (applicability) i.e. the worst situation is when you're not detecting false event -

thanks,
- dimitri.

I´d solicit other ccamp-ers also to comment on that.



--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491