The last two paragraphs imply the ALTO server uses the following update
strategy:
1. Automatically create a new network map from BGP (or whatever) routing
tables.
2. Automatically install & publish that new network map, without checking
for duplicate prefixes.
3. Wait for complaints, and when they arrive, rely on the admin to fix the
already published network map.
To me, that paradigm seems poorly designed. I think a better strategy
would be for the server to check for duplicates *before* installing the
new network map. I cannot believe that would tax any server's resources.
If the new map passes, fine -- automatically install it. If not, set it
aside and alert the admins. Or maybe take corrective action, such as
moving the duplicate prefixes to a dummy PID, install the corrected map,
and then alert the admins.
- Wendy Roome
On 11/10/2013 21:35, "[email protected]" <[email protected]> wrote:
>Date: Sun, 10 Nov 2013 20:15:29 +0000
>From: "Reinaldo Penno (repenno)" <[email protected]>
>To: "Y. Richard Yang" <[email protected]>, IETF ALTO <[email protected]>
>Subject: Re: [alto] New text on handling overlapping prefixes
>Message-ID: <cea52792.5c33%[email protected]>
>Content-Type: text/plain; charset="us-ascii"
>
>I'm not in agreement with the proposed solution because it puts even more
>burden on the client. I think the question one needs to ask before the
>jumping head first on the engineering solution is: what harm can
>overlapped prefixes cause?
>
>Assuming this would be a transient error condition, the worst possible
>situation is a client that flips a coin and picks a random PID. Remember
>that Applications that have ALTO clients should not rely on guidance to
>work, so an ALTO client should be always prepared to fall back to regular
>routing.
>
>The ALTO Server operator by this time should have looked at some log
>entry, detected the problem and will work on fixing it.
>
>-RP
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
