What I meant was the server logs the fact that the map has duplicate addresses, it does not wait for people to complain.
My reasoning is that if in the future we want to support duplicate addresses (multi-homing and whatnot) and we _prohibit_ duplicate addresses, we will be creating a server upgrade problem and having to change code and go through test cycle, etc. otherwise, some people will start talking about version negotiation and spending countless cycles on all possible features and permutations. This train is never late. On 11/11/13 7:14 AM, "Wendy Roome" <[email protected]> wrote: >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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
