About egress-influenced path computation in draft-dachille-inter-area-path-protection

[ricciato <ricciato@coritel.it>]

Dear ccmapers, Alan

I'm giving my comment to one question raised at Seoul by Alan to Vishal 
regarding the joint-selection with ARO of diverse paths, i.e. the 
approach proposed in 
<http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protection-00.txt>draft-dachille.
It was mentioned in point (v) of last mail from Vishal.

Consider a linear topology of ASs from AS(1) (the source AS) to AS(N) 
(the destination AS).
Denote by I(k) and E(k), respectively, the ingress and egress nodes to 
AS(k). Where needed, I'll distinguish between the ingress of the primary 
and secondary path, respectively, by I1(k) and I2(k). Same for th egress 
nodes (i.e., E1(k), E2(k)).

In the proposed approach, the selection process run as follows:

a. I1(k) selects the path-pair inside AS(k), thus explicitely 
determining I2(k), E1(k) and E2(k).
b. In the case that each single node E(k) has a single link to I(k+1), 
this means that I1(k) is implicitely determining I(k+1) too. Let's call 
this special case "1:1 border-nodes". I do not know if this is a common 
case in practice, or rather if each single border node is connected to 
>1 adjacent border nodes (anyone can comment on that ?)

If I understood it correctly, the Adrian´s point was: would it be 
possible to modify the scheme such that the egress nodes can influence 
the selection of the ingress nodes, by expressing some "preference" 
within the set of possible ingress nodes  ?

This sounds quite contradictory to the original scheme. In fact this is 
based on the following sequence of selections: I(k)-->E(k)-->I(k+1)-->... ,
while Adrian's approach would add to that a E(k)-->I(k) dependance.

One might think to a variation of the scheme in which the secondary path 
computation for AS(k), i.e. the ARO expansion,  is run during the RESV 
phase.
In this case, the selection sequence would be
I1(k)-->E1(k)-->{I2(k),E2(k)},
in place of
I1(k)-->{E1(k),I2(k),E2(k)} (see above point 'a')
However, this approach would break the joint-selection concept that, we 
think, is a key point of our approach (see my previous mail to Dimitri).

Another  possibility would be to carry two AROs, instead of one, thus 
having two secondary paths from which the downstream nodes (E1(k) or 
I(k+1) can choose.
However, the main drawback of this approach is that it is quite 
restrictive. Consider the case in which three paths are available that 
pair-wise disjoint, but not three-wise disjoint.
In this case it is not possible to expand two AROs with complete 
disjointedness constraints and the procedure fails, while there are up 
to three possible disjoint pairs to select.

Instead, if really one is willing to implement this capability (namely: 
"egress-driven selection"), several alternative solutions might be 
considered (e.g. partial "soft" cranckback, preliminary signaling, etc.) 
which however can not avoid some additional burden to the signaling 
procedure (at least, this is what I see now, but maybe I'm worng).

On the other hand, I would ask Adrian why it would be convenient to have 
this  "egress-driven selection".

In my humber opinion a possible answer might be that the egress nodes 
E(k) have knowledge about the load of inter-AS links E(k)-I(k+1), so 
that they can optimize the path selection taking into account the load 
on these external links, in addition to the load of internal links to AS(k).
If this is the case, my answer would be: why don't we let the ingress 
nodes I(k) be aware of the load state of downstream external links 
E(k)-I(k+1) ?
In fact, this information is already available to E(k), then I see no 
problems in sharing it with I(k) nodes since both are in the same domain 
AS(k).


This can be achieved quite easily. Consider the original scheme proposed 
in the draft xxx.
The ERO and ARO expansion is done at I1(k). The computation, however, 
can be run on the I1(k) node itself, or in a centralized route server 
that border nodes can query. In both cases the computation relies on a 
topology/load database (that, in a fully distributed environment might 
be fed by OSPF-TE Opaque-LSAs). So, why not augmenting this database to 
include external links also ? In both cases (centralized server, or 
OSPF-TE flooding) this does *not* require any protocol modification.
Note that both adjacent ASs will consider this information as "private", 
and will not export it to other ASs.

In conclusion, with this approach the ingress node I(k) would have 
exactly the same view of egress nodes E(k), so there is no additional 
benefit in having
"egress-driven selection".


I would aks you to comment on that. In particular, I'd like to know if 
you are aware of any other reasons or potential benefits for 
"egress-driven selection" beside that considered here. In this case we 
could further think about how to develop it in the framework of the ARO 
scheme.

Looking forwards to get more comments,
best regards

Fabio Ricciato