Re: Designing an IX with non-PI space peers

  • To: Barry Raveendran Greene <bgreene at cisco dot com>
  • Subject: Re: Designing an IX with non-PI space peers
  • From: "David R. Conrad" <davidc at apnic dot net>
  • Date: Tue, 29 Apr 1997 14:25:11 +0900
  • Cc: "'Miguel A.L. Paraz'" <map at iphil dot net>, "'apops at apnic dot net'" <apops at apnic dot net>, davidc at apnic dot net
  • In-reply-to: Your message of "Tue, 29 Apr 1997 08:26:25 +0800." <01BC5483.A3716D60 at bgreene-pc dot cisco dot com>
  • Sender: owner-apops@apnic.net
    • Hi,
      
      >	- ISP A advertises a /19 to the IXP members.
      >	- ISP B is a customer of ISP A, hence ISP B can point default to ISP A.
      >	- ISP B get's their IPv4 addresses from ISP A. They get allocated a /22.
      >	- ISP B advertises a /22 that is allocated from ISP A to the IXP.
      >
      >In this case another ISP at the IXP, say ISP C, who wishes to talk to any 
      >IPv4 address within ISP B's /22 will send directly to ISP B (the most 
      >specific route). When ISP C accepts routes from ISP A and ISP B via BGP, 
      >then ISP C would receive both the /19 and the more specific /22. Traffic 
      >bound for ISP B's /22 will go directly. All other traffic to ISP A's /19 
      >will go directly there. If for some reason ISP B is disconnected from the 
      >IXP, then ISP A's /19 will take over and traffic for ISP B will go through 
      >ISP A's link to the IXP - hence ISP B is backed up.
      
      One additional point -- as I'm sure you all know by now, some
      providers filter out long prefixes, thus in the scenario Barry
      describes above, the more specific /22 advertised by ISP B at the IXP
      can get filtered, thus you can end up with sub-optimal routing.  This
      is the part of the reason for the clause in RFC 2050 regarding
      multi-homing being a justification for address allocations...
      
      >+ Private ASNs at an IXP should be avoided. ASN's are not scarce. 
      
      Well... There are a total of less than 64K possible AS numbers.  Of
      those, 9000 or so have been allocated.  Of those allocated, about 2500
      or so show up in the routing system.  Of those, about 900 or so are
      actually useful in specifying routing policy (e.g., they define
      multihomed sites).  Given that multi-homing is a justification for
      obtaining portable space and to be multi-homed generally means you
      need an AS as well as the proliferation of regional IXes, I'd point
      out that AS numbers are as scarce as IPv4 addresses (yes, that can be
      taken in multiple ways... :-)).
      
      >> This leads me to the idea of allocating "country" IP space that is only
      >> routable/usable within a single country.  
      
      Address allocations should follow network topology.  If the network
      topology is such that all organizations within the country's Internet
      can be aggregated together, the concept of allocating addresses on a
      national basis would make sense.
      
      However such cases are a bit rare -- I know of none at this time.  The
      "problem" is that international connectivity for ISPs is rarely
      coordinated (for economic or political reasons, not technical).  As
      such, in order for routing to work, you end up having to announce gobs
      of more specifics from the "country block" for each ISP's portion of
      the country block.
      
      If there is good cooperation among the ISPs, there are various games
      you can play, however what would likely happen is one ISP ends up
      transiting more load than others, making them unhappy, and causing the
      good cooperation to break down.
      
      In the end, it is generally easier to obtain PI space and public
      ASes.  Don't worry, IPv6 is coming *real* soon now... :-).
      
      Regards,
      -drc
      _________________________________________________________________________
      To unsubscribe: send "unsubscribe" to apops-request at apnic dot net
      ------------------------------------------------------------------------