RE: Designing an IX with non-PI space peers

  • To: "'Miguel A.L. Paraz'" <map at iphil dot net>, "'Paul Ferguson'" <pferguso at cisco dot com>
  • Subject: RE: Designing an IX with non-PI space peers
  • From: Barry Raveendran Greene <bgreene at cisco dot com>
  • Date: Thu, 1 May 1997 08:10:44 +0800
  • Cc: "'apops at apnic dot net'" <apops at apnic dot net>
  • Encoding: 89 TEXT
  • Sender:
    • Hello Miguel,
      > From:    Miguel A.L. Paraz [SMTP:map at iphil dot net]
      > > I lean towards encouraging BGP peering in cases such as this, since BGP
      > > provides a higher granularity of policy demarcation. If the allocations
      > > came from the same provider, and exterior reachability is through the
      > > same allocating entity, this provides a high degree of aggregation for
      > > the visibility of these networks.
      > Here's a specific example.  I want to peer with ISP X, which has the
      > following networks allocated from MCI (this is a real example)
      > 1. Can ISP X get an ASN?  Assume they will always be routed to the rest 
      >    the net via MCI.  Why should they get an ASN just for 
      >    peering?
      Yes. Default goes to MCI (no BGP or full routing with MCI). You pull in 
      domestic routers from the other ISPs on the IXP.
      One option open to the PHIX (and has been strongly recommended) is to use a 
      router reflector and the BGP peering mechanism. Cost is a critical factor 
      with many IXPs in the region. So using cheap routers is a must. The problem 
      is that cheap routers will not be able to take a lot of BGP peer sessions. 
      Hence the route reflector.
      With a route reflector, you get one router - say a Cisco 2501 - and have 
      everyone do one BGP peer session with the route reflector. This would allow 
      ISPs to use small cheap router (that support BGP of course), use BGP for 
      the flexibility and filtering, and exchange traffic with each other.
      Only _one_ ASN is needed for this to work for all the ISPs at a route 
      reflector IXP. In fact, you may be able to twist APNIC's arm to get the ASN 
      for free, since you only need one ASN for the IXP - each ISP at the 
      exchange does not need one (thought they could use one if they choose to 
      use iBGP vs OSPF inside their network).
      The caveat is that you need to do a multilateral agreement on the IXP. In 
      other words, if you come to the IXP, you need to exchange traffic with 
      everyone on the IXP. Of course, you only exchange traffic that you 
      advertise - so there is some level of control.
      If you wish to see an example - look at HKIX. I've also got some PowerPoint 
      slides that describe the concept.
      > 2. If ISP X does get an ASN, I should take care not to leak it out to
      >    my upstream, right?  If they do not, and we peer using a private ASN,
      >    I should do the same?
      Actually, you need not do BGP with the upstream. So your ASN would only be 
      for domestic connectivity.
      > > I think you lost me here. If exterior reachability is required, then 
      > > RFC1918 space is a problem, unless you also deploy NAT. I would also 
      > > that NAT scaling is an issue which deserves close examination.
      > As with my reply to David's message... no exterior reachability is 
      > We want to have a "country network" that is not limited to a single ISP.
      > NAT can be useful though to condense the /16 into a /26 as in my example.
      History has shown that many networks that start their life as "private" 
      often end up as public - communicating to the world. In fact, at one time 
      it was recommended to get globally unique IPv4 addresses (before CIDR). Now 
      there is flexibility with RFC 1918 - but you need to keep in mind the 
      growth and traffic loads. There are NATs that can take 14K simultaneous 
      flows with 100M ethernet in and out. But what happens when you go above 14K 
      flows or 100M? Load balancing NATs is an idea, but it is still in work.
      Barry Raveendran Greene             |       ||        ||        |
      Senior Consultant                   |       ||        ||        |
      Consulting Engineering              |      ||||      ||||       |
      tel: +65 738-5535 ext 235           |  ..:||||||:..:||||||:..   |
      e-mail: bgreene at cisco dot com           |  c i s c o S y s t e m s  |
      To unsubscribe: send "unsubscribe" to apops-request at apnic dot net