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?
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
