IP ranges, re- announcing 'PA space' via BGP, etc
Folks, I see very often that customers in the US send morespecs all over the place, deaggregate whole /14s or such scary crap, ask us to accept random stuff out of 4/8 and 8/8 (L3 space) by example. I am practically asking what is (if any) the normal way for any of this. I am working by the principle that not everything I could do I should do, especially not right away. Is there any accepted procedure / policy for anyone to a) announce and b) accept (the transit supplier) and have that sanctioned formally? Maybe nobody cares, then tell me. ;-) Coming from Europe where pretty much everyone is RIPE LIR and has its own /21 at the least I might not see the problem that allegedly some (many) US ISPs do have. Enlighten me. (And, no, I do not fall for the urban legend that RIPE or ARIN are by default evil, clearly not. I do have real- life experience that whenever you can rightfully justify even large IP assignments you do get it.) Thanks, Alexander
On Apr 7, 2006, at 5:06 AM, Alexander Koch wrote:
I see very often that customers in the US send morespecs all over the place, deaggregate whole /14s or such scary crap, ask us to accept random stuff out of 4/8 and 8/8 (L3 space) by example.
I am practically asking what is (if any) the normal way for any of this. I am working by the principle that not everything I could do I should do, especially not right away. Is there any accepted procedure / policy for anyone to a) announce and b) accept (the transit supplier) and have that sanctioned formally? Maybe nobody cares, then tell me. ;-)
There is a lot of "nobody cares", but I'm not sure that accounts for everything you see. Can you give us some examples so us "dumb Americans" can more precisely explain the problem? :)
Coming from Europe where pretty much everyone is RIPE LIR and has its own /21 at the least I might not see the problem that allegedly some (many) US ISPs do have. Enlighten me.
(And, no, I do not fall for the urban legend that RIPE or ARIN are by default evil, clearly not. I do have real- life experience that whenever you can rightfully justify even large IP assignments you do get it.)
What if you try to justify small assignments? -- TTFN, patrick
On Fri, 7 April 2006 07:03:09 -0400, Patrick W. Gilmore wrote:
Can you give us some examples so us "dumb Americans" can more precisely explain the problem? :)
When a random customer (content hoster) asks you to accept something out of 8/8 that is Level(3) space, and there is no route at this moment in the routing table, do you accept it, or does Level(3) have some fancy written formal process and they get approval to do it, etc.? In Europe we would tell the customer this ain't gonna happen, as we would re- announce blocks out of 'foreign' LIR allocations and that is a no-go, unless the holder of that allocations acks that.
What if you try to justify small assignments?
I have done numerous /24 or /23 requests and my first hit approval rate is probably 90+ percent. RIPE only, I do not know ARIN. -ako
On Fri, Apr 07, 2006 at 01:13:19PM +0200, Alexander Koch wrote:
On Fri, 7 April 2006 07:03:09 -0400, Patrick W. Gilmore wrote:
Can you give us some examples so us "dumb Americans" can more precisely explain the problem? :)
He did.
When a random customer (content hoster) asks you to accept something out of 8/8 that is Level(3) space, and there is no route at this moment in the routing table, do you accept it, or does Level(3) have some fancy written formal process and they get approval to do it, etc.?
In Europe we would tell the customer this ain't gonna happen, as we would re- announce blocks out of 'foreign' LIR allocations and that is a no-go, unless the holder of that allocations acks that.
If there is clear expression of intent (SWIP/RWHOIS delegation) and the customer is multihoming then it is easy. If the customer isn't multihoming, verification of space portability is needed. If no clear published intent, allocation verification needs to be furnished preferably by the other provider. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Thus spake "Alexander Koch" <efraim@clues.de>
On Fri, 7 April 2006 07:03:09 -0400, Patrick W. Gilmore wrote:
Can you give us some examples so us "dumb Americans" can more precisely explain the problem? :)
When a random customer (content hoster) asks you to accept something out of 8/8 that is Level(3) space, and there is no route at this moment in the routing table, do you accept it, or does Level(3) have some fancy written formal process and they get approval to do it, etc.?
In Europe we would tell the customer this ain't gonna happen, as we would re- announce blocks out of 'foreign' LIR allocations and that is a no-go, unless the holder of that allocations acks that.
Here, it seems that some ISPs will accept foreign PA routes* _as long as the customer is still connected to that other provider_. Some won't under any circumstances. The remainder aren't filtering their downstreams and have no clue what they are providing transit for (i.e. it's the customer's job to get it right). If you do decide to accept a foreign PA route, you need to be very careful to point out to the customer (a) some people will filter your route for being too long and send their traffic to the owning provider, and (b) if the other provider doesn't announce the longer prefix in addition to their aggregate, anyone who accepts the longer route will send traffic only to you due to longest match. Both cases can result in suboptimal routing. The correct** solution is to help them become an LIR, assuming they qualify. S * meaning a route for part of another ISP's aggregate ** for some values of "correct" Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
On Fri, Apr 07, 2006 at 01:13:19PM +0200, Alexander Koch wrote:
When a random customer (content hoster) asks you to accept something out of 8/8 that is Level(3) space, and there is no route at this moment in the routing table, do you accept it, or does Level(3) have some fancy written formal process and they get approval to do it, etc.?
Initial instinct has to just be 'yuck', but in the interest of getting the job done, I'd look at : - how is it registered ? Are your customer mentioned ? - is it already a prefix which is announced seperately from the rest of the aggregated block ? - if the customer wants to multihome, have they even considered PI ? - are the customer happy for you to talk to the aggregating company ? are you happy to talk to them ? - it's still 'yuck'. -a
--On April 14, 2006 9:26:56 PM +0100 Andy Davidson <andy@nosignal.org> wrote:
On Fri, Apr 07, 2006 at 01:13:19PM +0200, Alexander Koch wrote:
When a random customer (content hoster) asks you to accept something out of 8/8 that is Level(3) space, and there is no route at this moment in the routing table, do you accept it, or does Level(3) have some fancy written formal process and they get approval to do it, etc.?
Initial instinct has to just be 'yuck', but in the interest of getting the job done, I'd look at :
- how is it registered ? Are your customer mentioned ? - is it already a prefix which is announced seperately from the rest of the aggregated block ? - if the customer wants to multihome, have they even considered PI ? - are the customer happy for you to talk to the aggregating company ? are you happy to talk to them ? - it's still 'yuck'.
Frankly, if the customer is multihomed, then, it might be preferable for them to go direct to ARIN for an end-user assignment. These are now available as small as a /22 since the adoption of policy 2002-3. Owen -- If it wasn't crypto-signed, it probably didn't come from me.
I would expect some sort of confirmation that Level3 has allocated the block to them - if there is no swip or RADB object, the customer should request that Level3 create one (or both). If Level3 cannot do either (unlikely) I'd request direct contact from Level3 confirming the allocation. -C On Apr 14, 2006, at 4:26 PM, Andy Davidson wrote:
On Fri, Apr 07, 2006 at 01:13:19PM +0200, Alexander Koch wrote:
When a random customer (content hoster) asks you to accept something out of 8/8 that is Level(3) space, and there is no route at this moment in the routing table, do you accept it, or does Level(3) have some fancy written formal process and they get approval to do it, etc.?
Initial instinct has to just be 'yuck', but in the interest of getting the job done, I'd look at :
- how is it registered ? Are your customer mentioned ? - is it already a prefix which is announced seperately from the rest of the aggregated block ? - if the customer wants to multihome, have they even considered PI ? - are the customer happy for you to talk to the aggregating company ? are you happy to talk to them ? - it's still 'yuck'.
-a
On 4/7/06, Alexander Koch <efraim@clues.de> wrote:
On Fri, 7 April 2006 07:03:09 -0400, Patrick W. Gilmore wrote:
Can you give us some examples so us "dumb Americans" can more precisely explain the problem? :)
When a random customer (content hoster) asks you to accept something out of 8/8 that is Level(3) space, and there is no route at this moment in the routing table, do you accept it, or does Level(3) have some fancy written formal process and they get approval to do it, etc.?
Btw, I hope you folks would defer to Level(3)'s reannouncement policy, which is very clear in their AS object located within RIPE's IRR, which reads: If you are a provider who has been asked to route a more-specific network block that is part of 4.0.0.0/8, please ask your customer to contact Level 3 to obtain a new network block. Level 3 will not accept advertisements for any networks that are part of 4.0.0.0/8 from any non-customer peer. So, if you want to do what's "right", tell your customer to go talk with Level(3), so they can renumber into IP space that would be permitted to be announced more specifically. If anybody wants to see the comments in their as object, just look at http://www.onesc.net/communities/as3356 it's very clear. charles
participants (8)
-
Alexander Koch -
Andy Davidson -
Charles Gucker -
Chris Woodfield -
Joe Provo -
Owen DeLong -
Patrick W. Gilmore -
Stephen Sprunk