Re: comments on ARO

[ricciato <ricciato@coritel.it>]

Hi Stefaan,

in addition to Vishal´s comment,  just let me quote below a paragraph 
from my previous mail 
(http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00473.html, Mon, 19 Apr 
2004).

I´d appreciate to have you opinion on it.

ciao
Fabio

> 3. The joint-computation with ARO can be applied to a vast class of 
> problems dealing with path-pair computation. I'm giving below some few 
> examples.
> (I think this also adrresses some comment by Jean-Louis). In general, 
> in each problem of path-pair computation one can distinguish the 
> constraint(s) from the optimization objective:
>
> Case-I: find a pair of disjoint paths (i.e., disjointedness is a 
> constraint) wich minimize some link metric (hop-length, link-load, etc.)
> Case-II: find a pair of maximally disjoint paths (disjointedness 
> becomes an objective)
> Case-III: find a pair of disjoint paths P1 and P2 that minimizes the 
> difference |d(P1)-d(P2)|, where d() is some metric associated to the 
> path (e.g., delay....might make sense in optical networks ??).
> Case-IV: Assuming that for each link pair (i,j) it is possible to 
> assign a "correlation" factor r(i,j) accounting for the probability of 
> contemporary failures, find a pair of paths that minimizes the 
> max{r(i,j)} over all pairs such that i is in P1 and j is in P2 [see 
> note 2].
>
> Maybe not all the above items are of practical interest in real 
> applications, but the fact that our approach encompasses all of them 
> proves the flexibility and usefulness of joint-computation with ARO. 
> Several other problems can be found.
> In general, joint-selection with ARO can address to all problems 
> presenting some *joint constraints* and/or *joint optimization 
> objective* on the pair of paths.
>
> Needless to say, each such case requires ad-hoc route-selection 
> _algorithms_ to be implemented in the ingress border nodes (or in a 
> centralized server within each AS), but all can be accommodated with 
> the signaling procedure based on ARO.
>
> Admittedly, the current draft version exclusively focused on case-I, 
> and fails to make it clear that the set of possible applications is 
> far broader. We will improve this point in the future version. 
> Incidentally, I notice here that this is indeed the reason why we 
> proposed the (quite neutral) term "Associated Route Object" instead of 
> the more specific "Disjoint R.O." or "Backup R.O." etc.: we wanted to 
> leave it open to a broad set of possible applications.
>
> Maybe it would make sense to add some additional semantic in the PATH 
> messages that specify the contraint(s) and/or the objectives to which 
> the primary (in the ERO) and secondary (in the ARO) paths should 
> (jointly!) comform.
> This might be an associated sub-object of the ARO, perhaps ?
> Might be named "Route Pair Requirements" (RPR) ?
> In other words, the overall semantic in the PATH messages should sound 
> like:
> "compute a primary route segment (in the ERO), and an associated 
> secondary route segment (in the ARO), such that they are subject to 
> the contraint(s) X and optimize objective Y (X,Y are contained somehow 
> in the RPR)".
>
> The ERO+ARO+RPR scheme, in the framework of distributed *joint* route 
> selection, would be really a quite flexible and general scheme.
>
> What do you think about that ?