APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists apops 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@apnic.net *