On Mon, Mar 12, 2012 at 8:04 AM, Bill Roome <[email protected]> wrote: > Okay! However, do you think it's worth adding an "implementation note" to > the protocol spec, warning people that they can't merge adjacent CIDRs in > the same PID, because that could change how endpoints map to PIDs?
Sure we can add that. Mind if I keep a note of this for the next round instead of uploading a -12 version today just for this? :) Rich > I know I considering doing that in my ALTO client. I was really surprised > when I investigated various test cases and discovered that I couldn't do > that safely. > > - Bill > > On 03/11/2012 15:00, "[email protected]" <[email protected]> wrote: > >>Date: Sun, 11 Mar 2012 00:23:37 -0800 >>From: Richard Alimi <[email protected]> >>To: Nicholas Weaver <[email protected]> >>Cc: Bill Roome <[email protected]>, "[email protected]" >> <[email protected]> >>Subject: Re: [alto] Pathological network maps: "empty" PIDs and >> "unreduced" PIDs >>Message-ID: >> <ca+cvdabgjj_damjgokxumsgxsefkguotgzgf7e29pwdvq-m...@mail.gmail.com> >>Content-Type: text/plain; charset=ISO-8859-1 >> >>On Wed, Mar 7, 2012 at 8:03 AM, Nicholas Weaver >><[email protected]> wrote: >>> >>>On Mar 7, 2012, at 7:57 AM, Bill Roome wrote: >>>>1. Should the ALTO spec forbid "empty" CIDRs in the network map? >>> >>>>2. Should the ALTO spec require the CIDRs in a PID to be reduced to >>>>"lowest terms"? >>> >>> >>>My thoughts are "No" and "No", because churn will happen. >>> >>> >>>For the first, the "empty" CIDRs can be effectively catch-all rules, >>>which when a subrule goes in and out may change things. >>> >>>Likewise, I don't see the benefit of mandatory >>>canonicalization/reduction when there is possible churn, which will >>>force the undoing/redoing of the canonicalization. >>> >> >>Agreed. While it may be aesthetically pleasing (and perhaps slightly >>smaller on the wire) to have a canonical representation, I'm not sure >>I see a reason to force this upon servers. >> >>Rich >> > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
