Re: [apops] Re: [Oz-ISP] Telstra Community support

  • To: "Joe Abley" <jabley at automagic dot org>
  • Subject: Re: [apops] Re: [Oz-ISP] Telstra Community support
  • From: "Phillip Grasso-Nguyen" <grasso at magna dot com dot au>
  • Date: Sun, 15 Apr 2001 01:50:47 +1000
  • Cc: <apops at lists dot apnic dot net>
  • References: <002e01c0c313$6897aee0$b4646fcb@PGLAPTOP> <v04220803b6fb25cbad63@[192.83.231.95]> <002501c0c42b$ccbc1550$6500a8c0@PGLAPTOP> <20010413113729.L19984@buddha.home.automagic.org> <006101c0c436$8af00e00$6500a8c0@PGLAPTOP> <20010414093213.A18845@buddha.home.automagic.org>
  • Sender: owner-apops@lists.apnic.net
    • Hi
      > 5511 is not passing these communities through to peers, though, which is
      > what you said you were asking for, wasn't it?
      I'm not sure what they are passing to peers, but they have set these
      communities for at least customers to provide some valid use.
      >
      > > endless possibilities.
      > Endless is a little over-enthusiastic :)
      ok, not endless :), but many good (and some bad) things can come with
      passing of transit communities.
      >
      > > means that service providers don't have to break cidr to control their
      > > inbound policies, also gives end providers a choice how their networks
      get
      > > routed, specially if some providers want to route around bottlenecks
      etc.
      >
      > The normal approach to routing around bottlenecks is to call your provider
      > and say "hey! there's a bottleneck there. you should fix your export
      policy
      > to avoid that."
      <Telstra bashing>
      "call your provider" have you ever tried to call Telstra support, imagine
      you favourite organization that likes to keep customers on hold for average
      between 20-45minutes, when getting on the phone gives you totally pointless
      information</Telstra bashing> ,,,,, there isn't much choice of large enough
      service providers in Australia.
      Whether the bottleneck is a long term problem with an transit provider, or a
      short term problem similar to a few of Telstra's recent ones (not entirely
      Telstra's fault). Available bandwidth is reduced to a crawl, and rtt's are
      coming close to 3seconds & this lasting for days, while having some options
      to route via other paths are very good! (there where attempts to stop
      advertisements to Telstra international route tables, but due to some
      mis-configuration our internal routes "in Telstra" where still be announced
      internationally). Besides that gives one the option for more fine grain
      control of inbound route policies.
      >
      > You are asking Telstra to offload the job of fixing their transit issues
      > onto their customers. To some extent, this is similar to them just
      providing
      > you with telnet access to their routers, and saying "if you need to make
      > changes, go ahead" :)
      Yes and No, Obviously the problem is not just with Telstra but with most
      transit providers, it is almost mandatory that you always localpref
      customers before peers, and peers before upstreams. I agree with this for
      most routing scenarios, but this is the same reason why so many people break
      CIDR, and announce smaller prefixes out preferred links, I would "assume"
      that if someone had enough brains(this is obviously debateable :-) ) to
      announce longer prefixes via other providers to control inbound policy, they
      would also know to use advanced community support if available whereby not
      increasing global table size.
      a quote from someone we all know :-)
      >>Most networks already give control of their routing policy to remote
      >> networks, by virtue of longest-prefix wins.
      So how much more does it hurt to give your transit customers the option to
      control beyond the next hop AS, how much more functionally without making it
      difficult. I suppose if you really wanted to be difficult you could
      implement the edge filtering with something similar to the old access-list
      112 by Sean Doran, but then we go back to the not knowing the true network
      path, and black holing networks. - ( yes this someone also mention this in
      "verio-style edge filtering").
      What about things that like,
      - edge cache policy propagation? where a hosting provider decided to do
      reverse transparent caching, being put on the cache or even off caching can
      be achieved via simple community
      - QoS policy propagation? where certain network traffic can be modified to a
      high precedence or QoS group via communities, and on billing can be done via
      Netflow?
      obviously these things can be done already, but so much more can be done!.
      Regards
          Phill.
      
      *             APOPS: Asia Pacific Operations Forum              *
      * To unsubscribe: send "unsubscribe" to apops-request at apnic dot net *