Re: IANA IPv4 Recovered Address Space registry updated

2017-03-04 Thread Nathan Brookfield
https://www.iana.org/assignments/ipv4-recovered-address-space/

Nathan Brookfield
Chief Executive Officer

Simtronic Technologies Pty Ltd
http://www.simtronic.com.au

On 5 Mar 2017, at 11:29, Doug Barton 
> wrote:

Paula,

Thank you for this update. Is there a convenient resource for viewing the delta?

Doug

On 03/01/2017 12:15 PM, Paula Wang wrote:
Hi,



An update has been made to the IANA IPv4 Recovered Address Space registry 
according to the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms 
by the IANA 
(https://www.icann.org/resources/pages/allocation-ipv4-post-exhaustion-2012-05-08-en).



The list of allocations can be found at: 
https://www.iana.org/assignments/ipv4-recovered-address-space/



Kind regards,



Paula Wang

IANA Services Specialist

PTI




Re: IANA IPv4 Recovered Address Space registry updated

2017-03-04 Thread Doug Barton

Paula,

Thank you for this update. Is there a convenient resource for viewing 
the delta?


Doug

On 03/01/2017 12:15 PM, Paula Wang wrote:

Hi,



An update has been made to the IANA IPv4 Recovered Address Space registry 
according to the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms 
by the IANA 
(https://www.icann.org/resources/pages/allocation-ipv4-post-exhaustion-2012-05-08-en).



The list of allocations can be found at: 
https://www.iana.org/assignments/ipv4-recovered-address-space/



Kind regards,



Paula Wang

IANA Services Specialist

PTI





Re: google ipv6 routes via cogent

2017-03-04 Thread Patrick W. Gilmore
On Mar 3, 2017, at 9:05 PM, Job Snijders  wrote:
> On Fri, Mar 03, 2017 at 09:42:04AM -0500, Patrick W. Gilmore wrote:
>> On Mar 3, 2017, at 7:00 AM, Nick Hilliard  wrote:
>>> Niels Bakker wrote:
 As I explained in the rest of my email that you conveniently didn't
 quote, it's so that you can selectively import routes from all your
 providers in situations where your router cannot handle a full table.
>>> 
>>> it can also break horribly in situations where the provider is providing
>>> "transit" but doesn't provide full transit.
>>> 
>>> OTOH, if you are single-homed, it is highly advisable to accept a
>>> default, the reason being that most transit providers provide bgp
>>> communities with "don't advertise to customers" semantics.  So if you're
>>> single-homed and use a full dfz feed without default route, you will not
>>> have full connectivity to all the routes available from the transit
>>> provider.
> 
> Correct.
> 
>> If you are single-homed, there is no need for BGP at all.
> 
> That is very strongly worded, and in plenty of cases a false assertion.
> 
>> And injecting your ASN into the table is probably not terribly useful
>> to everyone else’s FIB.
> 
> ASNs don't have anything to do with FIB.
> 
>> There are, of course, corner cases. But in general, single-homed
>> people shouldn’t be using BGP.
> 
> There are numerous reasons to use BGP when single-homed:
> 
>- as preparation to multi-home in the (near) future
>- ability to quickly change providers
>- to use BGP based blackholing features
>- to save time on provisioning work (adding new prefixes becomes a
>  matter of just announcing and updating IRR/RPKI).
>- loadbalanacing / loadsharing across multiple links
>- ability to use bgp communities for traffic engineering
> 
> In other words, if you have your own IP space, I'd recommend to get your
> own ASN and use BGP.

First, I said specifically there are corner cases. Everything you say above is 
a corner case. The sum of everyone in need of the above is to the right of the 
decimal compared to all single homed networks. Limiting it to “it you have your 
own IP space” makes the set even smaller.

You are also reaching here. Preparation for multi-homing in the near future is 
just multi-homing. Adding prefixes is a very occasional thing, and in some 
cases is actually not easier with BGP. (Ever worked with some provider’s IRR 
implementation?) Etc.

End of day, if you have your own space and only allow aggregates into the DFZ, 
even as a stub behind someone else, it doesn’t really save RIB slots compared 
to having the upstream announce it for you. My problem is making the exceptions 
sound normal. They are not, and we should not treat them as if they are. Else 
we will end up with people wanting to do it who do not understand what they are 
doing, polluting the table, etc.

I stand by my statement. Single Homed Networks Should Not Use BGP. It is a good 
general rule. There are exceptions, but the exceptions are rare and should be 
approached with caution & clue.

-- 
TTFN,
patrick



Re: google ipv6 routes via cogent

2017-03-04 Thread Baldur Norddahl
 In general I would not be single homed to a tier 1 ISP. You are better off
using an ISP that has N upstream transit providers. That way they have
multiple choices to select the best route.

If you accept a default route from multiple upstreams you will be multi
homed for inbound traffic but effectively single homed for outbound. Your
router will select one default route and send 100% of the traffic that way.

Instead of letting the router select a random default route, you should
evaluate and rank your upstreams. Use a route map to set priority on the
routes.

Nobody has the best routes for all destinations, so you will have to find
the one with the best average or perhaps the one that avoids bad routes.
And that brings me to the point about Cogent.

We used to have two upstreams. One was a local tier 2 ISP and the other was
Cogent. Our quality was OK but if the tier 2 ISP link was down our
customers would immediately call to claim downtime. We would not actually
be down but quality was so low that people thought we were.

The reason is that some major destinations from the Cogent network is
routed from Europe to USA and back again. Latency go from a few
milliseconds to 100 times worse. Available bandwidth is very reduced. Video
from major streaming services will not play or only in lowest quality
setting.

I will claim that it is impossible to be single homed on Cogent in Denmark
as an eyeball network. It is probably different if you are in the USA.

This does not mean Cogent are useless. We were happy with the quality of
the network and the price is good. What we experienced was bad peering. You
just can't have them as your only transit.

Regards

Baldur

Den 2. mar. 2017 21.02 skrev "Chuck Anderson" :

Define "good" vs. "bad" transport of bits.  As long as there is
adequate bandwidth and low latency, who cares?

On Thu, Mar 02, 2017 at 08:30:37PM +0100, Baldur Norddahl wrote:
> That will have the effect of prioritizing Cogent routes as that would be
> more specific than the default routes from the other providers. Cogent are
> not that good that you would want to do that.
>
> Den 2. mar. 2017 20.16 skrev "Jeff Waddell"  >:
>
> Or at least ask for a full view from Cogent - then you won't get any
routes
> they don't have
>
> On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay 
wrote:
>
> > On jeu.  2 mars 12:36:04 2017, Aaron Gould wrote:
> > > Well, I asked my (3) upstream providers to only send me a ipv6 default
> > > route and they sent me ::/0...here's one of them...
> >
> > Why did you don’t ask for a full view? With that, you can easily deal
> > with that kind of problem.