[c-nsp] Humor: Cisco announces end of BGP

Kevin Loch kloch at kl.net
Wed Jul 29 15:06:10 EDT 2009


TJ wrote:
>> -----Original Message-----
>> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>> bounces at puck.nether.net] On Behalf Of David Freedman
>> And what, prey tell is wrong with "/126 on point to point links", you want
>> to use SLAAC between routers?
> 
> Nothing is wrong, per se.  It certainly works.  Oh, and I don't believe I
> said anything about SLAAC.
> However, there have been numerous conversations back and forth, on many
> sides of this.
> 
> My feeling is based on two things:
> I don't like the idea of vendors/providers ignoring an RFC just because.  
> 	And note the RFC in question leaves no wiggle room here.
> 		If a different solution is better, codify it in a draft, get
> community consensus and get it ratified in a RFC.
> 	Not saying the IETF is always right, but I'd prefer any such
> disagreement gets vetted by as many eyes as possible.
> 		In this case there are lots of things that assume 64bits of
> host space - most aren't relevant to PtP links, but still ... 
> 	
> Aggregation
> 	IMHO the most efficient solution is to burn one of the client's /64s
> on the client-facing link 
> 		... one covering prefix for entire client, including CPE.
> 
> IIRC there was some chatter about using /127s (again), dumping the subnet
> router anycast address (for security reasons, I believe).
> 	I'd have the same thing to say to that conversation - get some loose
> consensus pre-implementation.

Lots of folks, myself included use /112 for point to point links, server
only subnets and just about anything that doesn't require RA's (which is
almost everything in a hosting environment).  /112 is a convenient
bit boundary to work with and one size fits all (p-p and multipoint)
applications.

> In closing, I guess I would turn it around and say "provide me a "really
> good reason" to not use /64s as dictated" ...

Making it difficult for autoconf to work on certain subnets is a big
plus.

- Kevin


More information about the cisco-nsp mailing list