Hi Ramesh,
ramesh.chandra@airtel.in said the following on 22/08/11 23:41 :
Philip, I hope, you hv not understood the case and proposal. A
multihomed customer shall announced one prefix to upstream providers
rather 10 IPv4 prefixes being announced today because he has go these 10
prefixes in 10 different times from APNIC or ISP. Same case with non
multihomed BGP customer.
This is not the case. If you actually look at the examples I gave, you
will see that the AS4755 /14 is being chopped into many small pieces.
AS4755 did not go back to APNIC lots of times to get lots of different
bits of address space. They got that ONE allocation, and are now
subdividing it way beyond what typical traffic engineering requires.
I'm not selecting AS4755 deliberately - we can choose many ASNs from
across the region and see the same thing happening. Take a look at my
last Routing Table Report at the previous SANOG, for example:
ftp://ftp-eng.cisco.com/pfs/seminars/SANOG17-Routing-Update.pdf. Pick
any of the ASNs highlighted in blue in slide 21, pop them into the CIDR
Report's AS analyser, and look at the address blocks they have received,
and observe how each one has been subdivided into very small pieces.
None of this was caused by these providers getting lots of little pieces
of address space from APNIC - it was all caused by the ISPs themselves.
ISP can not aggregate prefixes received from
BGP customers. However, ISP can aggregate for prefixes used with static
routing. Hope, this clarifies.
Not at all, unfortunately. Agreed an ISP cannot aggregate what is
received from a BGP customer (although some make a practice of doing
so), but the examples I showed are prefixes being originated by one AS.
Static routing doesn't do any aggregation. BGP originates prefixes - the
ISP decides what prefixes they put into BGP, and by implementing
appropriate filters towards their neighbouring ASNs, they decide what
gets announced to the world.
Industry best practice for the last 20 years has been to announce the
address block received from the registry as a single unit. The only
subdivision deemed acceptable is that for traffic engineering (ie load
balancing) purposes. If you look at the deaggregation factor in my
report (slide 19 of the earlier reference), you will see that operators
in the RIPE NCC and ARIN regions manage to deaggregate by less than a
factor of 2. The networks in those regions are more densely meshed and
have more challenging traffic engineering requirements than most
networks in the APNIC region, yet they only need to announce less than
twice the total of the discrete blocks they have received from their
RIR. So when I see an ISP in our part of the world announcing 1564
prefixes, of which 1485 are totally unnecessary (a deaggregation of
almost 20 fold),...
philip
--
