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@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0