Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote:
with the result there are now likely to be 50% more adverts (i.e. 2x/19 and an additional /18 - /19 still necessary to get ANS to work as you can't put a /18 route object in the database).
Yes you can! If you have a /18 allocation you should announce it as such and put a /18 route object in the database. Can you be more specific on why it did not work for you?
Sorry I wasn't clear. If you have a /19 allocated in the RIPE database then for obvious reasons you have to put a /19 route (not a /18) route in the RIPE database. To get ANS to accept this you have to announce a /19 route for this. This got filtered by Sprint. Before Sprint's (much welcomed - thanks Sean) change of heart, you could get around this if you were the lower /19 in the block by also making a /18 advert. As the other half of the /18 was unused normally, this makes no difference to anyone except those in the /19 suddenly get Sprint connectivity. Actually it was likely to be of benefit to any future holder of the upper half of the /18 as that would have been the only way they would have gained Sprint connectivity (effectively the holder of the lower half gives them partial transit to the point where the upper /19 advert hits the /18 route to Sprint). This possibly slightly naughty but oh-so-tempting hack would have meant that European local IRs were likely to announce a /18 and a lower /19, and an upper /19 rather than just two /19s. So Sprint would see one /18 and get suboptimal routing, everyone else would see 3 adverts rather than 2. Hope that makes sense. Anyway, all sorted out now Sprint have changed their policy. Glad the world has seen sense (i.e. RIPE and Sprint have agreed on the same size - whether it was /18 or /19 didn't matter to me, just as long as it was consistent). Alex Bligh Xara Networks