Re: [sig-policy] Pro-100:National IP Address Plan - Allocation of countr
will last them many (many!) years to come. If that enterprise obtains
address space from their ISP, it's possible for their route to be
aggregated with their ISP's.
The question I asked earlier gets to the point. The only way you will
announce a single aggregate, or something less than the number of
allocations made by the RIR, is if (as a country) you intend to
announce a single aggregate to the world (or small handful of
prefixes) If all of the delegations you make from the /16
reservation, are still announced singly as routes, from disparate
ASN's - then you do not achieve any savings in the routing table.
Do not compare the number of routes that are announced by an
organization in IPv4 today, to the number of v6 routes that
organization will announce in the future. The number of v4 routes
today is not a good model, because organizations grew rapidly as they
enabled internet services.
--Heather
On Fri, Aug 19, 2011 at 9:54 AM, <ramesh.chandra at airtel dot in> wrote:
>
> Hi Randy,
>
> Appreciate your query and let us look at simple Engineering example for a
> Enterprise house. One Enterprise customer manage 10 IP pools allocated to
> him as per his business demand in previous years. He is announcing these 10
> routes in BGP to upstream carriers, NAP/NIXI and other private peering he
> has with others. Every connected BGP listner has to process every 60 seconds
> these 10 routes and install in routing table and this continues to thousands
> of routers in Internet.
>
> If these 10 pools become one continuous block then these thousands of
> routers shall scan and install one route instead 10 routes in previous case
> under that AS. This helps to reduce few CPU cycles and these CPU cycles
> become significant when we talk thousand routers repeating the same. Lesser
> routes in BGP required less time to install and hence faster Convergence
> time. Presently, convergence time for 10k IPv4/Ipv6 routes takes approx 1
> second. Convergence time shall reduce significantly when everyone summarise
> their own routes before announcing.
>
> Same logic holds good for freeing memory. One IPv4 occupy one 1KB memory and
> more in IPv6. If 10 routes become 1 then it free up memory used to install
> these 10 routes by approx 90%. If we look at holistic view in Internet, this
> becomes significant..
>
> In DNS, enterprise has to have one entry for reverse lookup instead 10
> entries and helps DNS to respond slightly faster. You can calculate number
> of DNS worldwide see improvement in performance.
>
> On other hand, what do we loose? Nothing. Little change in mindset from what
> we are used to. Do you think, this is going to benefit everyone. Hope, this
> clarifies your concerns and look frward to your support.
>
> regards
> Ramesh Chandra | GM – Network Engineering | NSG | Bharti Airtel Limited |
> Phone# +91 124 4243897, 9810300704
>
> This e-mail and any files transmitted with it are for the sole use of the
> intended recipient(s) and may contain confidential and privileged
> information. If you are not the intended recipient, please contact the
> sender by reply e-mail and destroy all copies and the original message. Any
> unauthorized review, use, disclosure,dissemination, forwarding, printing or
> copying of this email or any action taken in reliance on this e-mail is
> strictly prohibited and may be unlawful. The recipient acknowledges that
> Bharti Airtel Limited or its subsidiaries and associated
> companies(collectively "Bharti Airtel Limited"),are unable to exercise
> control or ensure or guarantee the integrity of/overthe contents of the
> information contained in e-mail transmissions and further acknowledges that
> any views expressed in this message are those of the individual sender and
> no binding nature of the message shall be implied or assumed unless the
> sender does so expressly with due authority of Bharti Airtel Limited. Before
> opening any attachments please check them for viruses and defects.
>
> * sig-policy: APNIC SIG on resource management policy
> *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>