j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
There are customers both Multi homed and non multihomed. Trading and
renumbering is not possible because ISPs and APNIC allocate IPs from
different pools. This is precisely the solution proposed to address by
assigning bigger pools.
How does that work?
If a customer is multihomed then by definition their route is going to be
not able to be aggregated. Irrespective of the external view, within a
country the route will need to be visible to all at the IXPs within that
country otherwise it defeats the purporse of multi homing. Bigger blocks
doesn't solve this fundemental. If a customer is single homed then their
space can be aggregated anyway irrespective of the block size.
Then we get to the whole issue of deliberate deaggregation for traffic
engineering. (eg. http://thyme.rand.apnic.net/current/data-ASnet-APNIC - >if companies _actually_ cared about the route polution through deaggregation then this report wouldn't show such sad data.
Bigger pools or country specific pools aren't going to change any of
these fundementals. If the desire is for larger blocks then let's focus on >fixing that for everyone in the APNIC IPv6 allocation policy rather than focusing on selfish needs within our own countries.
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. ISP can not aggregate prefixes received from BGP customers. However, ISP can aggregate for prefixes used with static routing. Hope, this clarifies.
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.
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.
entirely bogus. EACH, read again, EACH of most indian (and many other asian) isps' address blocks are being announced as a horrifying number of /24s.
can we please focus on facts and engineering, not political fantasy?
firstname.lastname@example.org 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),...
- 4303 days inactive
- 4303 days old
- 3 participants
- 2 comments