Addressing versus Routing (Was: Deploying IPv6 in a datacenter)

Tue Dec 27 19:12:34 UTC 2005

On Thu, Dec 22, 2005 at 11:56:07AM +0100, Jeroen Massar wrote:
> Correct. One of the few solutions you can do is setup connectivity (VPN
> or so) of your own between them.

Oh excellent idea. Pushing traffic twice through the upstream pipes? I'm
sure the upstream ISPs will be very happy about such a model.

> This is a routing issue.

No, it's an economic issue.

> > All three add 6 entries to your table.
> 
> Which is where the 'big problem' lies for some people, for the
> foreseeable future (say coming 25 years) this will go fine, but after
> that will it still go fine?

I will only care about problems which MIGHT come up in 25 years if there
is a compelling rationale that we won't be able to cope with it THEN.
:-)

> Daniel Roesen wrote:
> > Uhm, sorry, but that's wrong. /24s are widely(!) accepted and only very
> > seldom not accepted. There are many (MANY!) folks running on /24 PI
> > (== no larger covering aggregate) without problems.
> 
> Oops I meant to type "smaller than /24" (thus /25's, /26's etc) :)

OK, that's correct then.

> The point I intended to make: ISP's make the policies in what they
> accept, not the RIR's.

Indeed. This is why I'm interested to see how the whole "/48 except
proven technically never needed in future" policy idea will work out in
reality. Consider me pessimistic. Beancounters will prevent that prolly.

> There are also sites that filtered on larger than /32.

Yep, folks who didn't understand CIDR and thus don't understand that
less-specifics aren't a threat at all. Very annoying. Even more annoying
to see popular filter recommendations STILL promoting such nonsense.

> This is similar to Bogon Prefix filtering where ISP's don't update the
> filters.

It's exactly that. Except one case where I got an answer along the lines
of "we think /21 is too big an allocation and have to make a policy
decision wether we'll accept such a large prefix". No kidding. Made my
day (year). Took some days or week (cannot remember) until the filters
got finally opened.

> > Shim6 and others are interesting, and solve multihoming issues for some,
> > but they don't address traffic engineering or the need to do more with
> > smaller allocations.
> 
> If you see these issues then participate in the SHIM6 working group and
> explain these issues and suggest how you can solve them. Just like the
> RIR's, IETF has an open process and anybody can participate. But do
> bring valid justifiable arguments.

No. SHIM6 is already a narrowed-down solution space. You'd be advocating
resurrecting the multi6 WG, which was closed after it's failure to
agree on any way forward that would cover ALL requirements people
brought forward.

Whining on the SHIM6 mailing list that SHIM6 is not the solution folks
are looking for is certainly not the right place. It would have been
multi6. SHIM6 is already the dead-end street, not the junction where you
discuss wether you take the road to the left or the right. :-)

> Daniel Roesen wrote:
> >>  This is the very hard part. (political and technical)
> >>  But it might be years before we will hit the actual limits of BGP.
> >>  We still have to be nice to our kids though as they will hit it ;)
> >
> > Really? Where are the limits of BGP? Can you show me any numbers?
> > You'd be the first. I'm not aware of any protocol inherent scaling
> > brickwalls like with other protocols where certain timing constraints
> > place limits (or thinking of L1 systems, you remember CSMA/CD?).
> > That doesn't mean that there are none - I'm not a scientist or
> > mathematician - I'd be happy to have any numbers to back the FUD about
> > the end of world being near. :-)
> 
> Which part of "it might be years before we will hit" did you ignored? :)

Non. I just ask what this "it" is. Define it. :-)

> But as we had a nice example above (LA/NY office), lets that that.
> Lets say we have 1.000.000 companies, they all have say 10 offices, thus
> they all want to announce separate /48's, that brings us to 10.000.000
> /48's. Do you have equipment to support that?

No. Do we have this kind of DFZ yet? No. So what's the relevance of that
question?

> Current IPv4 BGP contains about 170k prefixes. And remember that it
> might just be that say 500k routes suddenly all change because they
> are actually going over the same transit who has a failure somewhere.

You are comparing oranges (today IPv4 DFZ) and apples (a possible future
IPv6 DFZ). If we align IPv6 PI policy to current IPv4 policy AND would
assume that everbody who runs an active ASN in the DFZ suddenly starts
announcing an IPv6 PI block in the DFZ, we'd be at 190k instead of 170k
routes. I don't see any problem with that. If you do, you'd have to
fight IPv4 PI policy as well.

> (Funnily I see people complain about the current policy and limits they
> "have been laid upon" but they never seem to come forward with an actual
> proposal which satisfies their needs, complaining doesn't help, small hint)

Chose your battles wisely. Or to put it differently: don't begin a war
you cannot win. You should first have a good idea of the amount of
support that would get. Currently I do not see enough momentum to
succeed in the various RIR policy development fora (at least ARIN and
RIPE, not too familiar with the other ones). And that will prolly not
change until the policy voting process changes from

 "let's see who can cry loudest and invest most time and money into
 flooding mailing lists with postings and make appearances at
 conferences"

to

 "let all relevant people with interest in the RIR region simply vote"

That of course means not only letting the LIRs vote about such things as
the LIRs are not the ones who like to see such a policy succeeding. :-)

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0