Security issues and egress-driven path comput in draft-dachille-inter-area-path-protection

[ugo monaco <monaco@infocom.uniroma1.it>]

Dear ccampers, Adrian,

as anticipated in the recent email by Vishal we are addressing 
several important comments collected at Seoul regarding the joint-selection 
of diverse paths with ARO, i.e. the approach proposed in 
<http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protection-00.txt>.

As mentioned by Vishal I summarized your comments to ensure that we rightly
understood inputs, and to help people on the ML follow
and contribute to the discussion.
Comments from others who have feedback are welcome, and
much appreciated.

Please let me know if you had any additional comments
as well. We will take these into account in providing our
responses, and, later, in updating the document.



Thanks again for your feedback on our draft during the Seoul meeting.
Best Regards.

Ugo Monaco

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


i) Security issue of intra-area/AS specific information across areas/ASs.
The problem is that ARO could provide private intra-area information outside 
the area/AS.

ii) You asked if our proposed scheme could be modified to have the path 
for the secondary be computed when the Resv for the primary arrives at 
the border router of each area/AS? 
This might allow the egress node (and subsequently the exit node at 
each previous area/AS) to choose the entry point for the secondary 
into that area/AS.

For example, refer to the attached figure. Consider a linear topology 
of ASs from AS(1), the source AS, to AS(3), the destination AS.
Denote by I(k) and E(k), respectively, the ingress and egress nodes to 
AS(k). Where needed, the ingress of the primary and secondary path, 
will be respectively referred to by I1(k) and I2(k) and same for th egress 
nodes (i.e., E1(k), E2(k)).

Your point was that by computing the path in the forward direction, 
the entry of the secondary path into Area 3 might be I2(3), where as 
the egress Z may have preferred that it be "Y".
By computing things in the reverse direction, one would give the egress 
the flexibility to choose that entry point, and it could therefore choose "Y".
But this way, the exit point at the previous area should be fixed to "X".



     Area 1                   Area 2                     Area 3
    +----------+             +-----------+             +----------+
I(1)/+\        /+\-----------/+\    E1(2)/+\-----------/+\I1(3)    |
    |          |             |           |             |          |
    |          |             |           |             |         /+\ E(3)
    |          |             |           |             |          |
    |         /+-------------+\    E2(2)/+\-----------/+\I2(3)    |  
    |          |             |           +             |          |
    |          |             |        X /+\xxxxxxxxxxx/+\ Y       |
    +----------+             +-----------+             +----------+


Please note that some details and comments dealing with this "egress-driven 
selection" have been collected in a previous email posted by Fabio Ricciato on the ML 
"About egress-influenced path computation in draft-dachille-inter-area-path-protection".
Further comments and notes on this issue are welcome.


iii) You asked also info. about how ARO relates to the following objects:
--- S-ERO, proposed in the draft dealing with setting up p2mp tunnels 
for multicast (on which you are a co-author);
--- Primary Path Route Obj (PPRO) in the e2e protection draft (draft-
lang-recovery-e2e, which is now draft-ietf-ccamp-recovery-e2e).


iv) Your other question was, how does one select inter-area or inter-AS links
when there is dense connectivity between them? Again, referring to the attached
figure, if there are multiple choices to get from one area/AS to another, how 
does the scheme pick one of them?