On Oct 8, 2007, at 6:45 PM, Justin M. Streiner wrote:
On Mon, 8 Oct 2007, Patrick W. Gilmore wrote:
It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go.
That is not at all guaranteed.
I never said it was. My experience, both in my previous life as the operator of a regional ISP and since then in other capacities is that having disjoint origins for a chunk of some provider's address space is basically asking for trouble, and it's the kind of trouble that may ony pop up when something breaks.
I'm afraid your experience is not the same as many, many people. There are currently ~1500 prefixes with inconsistent origin AS. These are trivially identifiable: <http://www.cymru.com/BGP/incon_asn_list.html> Some of them are obvious mistakes (I doubt HKSuper is supposed to originate 4/8). But many of them are not, and the Internet works just fine.
My experience has also been that if a customer has a need to multihome and is willing to invest both in the equipment and the expertise to do so, then so be it.
That statement does not say anything.
If you do you have permission from the owner of the block, you Should Not Announce it.
Agreed.
If the owner gives you permission and can't figure out why their block is originated by another ASN as well, they need help. (Yes, I realize the latter part of the last sentence is probably true for the majority of providers, but whatever.)
In either case, your hypothetical question should not hold.
Also, if some network out there aggregates prefixes in an aggessive/odd manner, the disjoint announcement, and the reachability info it contains could be washed out of their routing tables, causing connectivity problems.
How is this different than if the customers gets their own ASN and announces a sub-block from one of the providers?
In the case you described, the provider who holds the parent address block should expect to see an advertisement for a chunk of that block come in as part of the BGP feeds they receive from their upstreams, and they need to accept traffic accordingly. The customer would need to tell the provider of their intentions to multihome. If the provider in question employs some type of ingress/egress filtering, that filter would need to be updated to recognize that traffic sourced from that sub-block as legitimate, even if it comes in over their normal transit pipes.
In the case I described, where the end user requested that a third party provide transit for their PA space, without that provider necessarily being aware of it is when things can break in strange and spectacular ways.
I stated above that you should not announce another provider's space without their permission, and you specifically agreed. Here you are talking about that space being announced without the owner's knowledge. Make up your mind. We both agree that announcing another provider's space without their consent is a Very Bad Thing. I doubt you will find people willing to post here to the contrary. If the owner _does_ know the space is being announced, the edge filters are no different whether it is originated in the second upstream's ASN or an ASN owned by the customer. So again, I ask, how is that different?
Or are you suggesting they should get PI space?
PI space, while nice, is not an option for many end users.
Which is why I was assuming you did not mean PI space, but wanted to ask in case you were going to suggest it. -- TTFN, patrick