[ppml] 2005-1 and/or Multi6

[Daniel Roesen]

On Thu, Apr 14, 2005 at 02:27:59PM +0100, Michael.Dillon at radianz.com wrote:
> I don't whether or not BGP can reduce the number of bits in its
> communications when the prefixes are shorter, however, if
> the number of bits communicated between peers becomes an
> issue, then the protocol could evolve to be more efficient
> in its use of bandwidth. The only place where IP addresses
> need to be in fixed length fields is in the IP packet headers.
> I am not referring to packet headers here, but to the data
> transmitted by the protocol.

ACK. But then we'd need BGP5. Question is, wether we shouldn't THEN
actually move to a new model which really seperates identity and locator
_from_the_beginning_ and not crammed over IP/TCP/...

> Also, I don't believe that the current details of BGP are
> relevant to the policy. BGP is software and it can evolve
> very quickly if it needs to.

I tend to agree.

> Physics is the ultimate in hardware and does not evolve at all.

But knowledge about physics does.

> > Please don't go back to pre-CIDR, really.
> 
> Even if we defined IPv6 to have three classes of address,
> Class X = /32, Class Y = /48 and Class Z = /64, it is still
> not the same as pre-CIDR. The number of possible entries in
> each of these classes makes it fundamentally different from
> the classful IPv4 addressing scheme.

We do have that _almost_. We have "link" (/64) and "site" (/48),
and ISP (/32 by default).

> And I am definitely NOT proposing classful IPv6. Some ISPs
> already have prefixes shorter than /32 and the ability to 
> announce a single shorter aggregate prefix is a GOOD THING.

OK.

But if you agree that CIDR is still favorable, you cannot optimize for
certain "magic" prefix lengths at the same time.

Don't forget that the most optimization is probably (vendors may correct
me here) desirable in the longest-match algo used to determine
forwarding decision. You cannot optimize there for /32, as WITHIN your
AS, all forwarding decisions follow IBGP more-specifics anyway... which
are really arbitrary length between your aggregate length and /64.

> > Oh? Any scientific reference to that?
> 
> Here is one scientific paper
> http://www.intel.com/research/documents/Bourianoff-Proc-IEEE-Limits.pdf

Thanks, will look into this.

Hope I'll be able to derrive the average computing power of routing
engines in 2015 from that. Or even the absolute upper limit. :-)

> > I can remember modem manufacturers saying that when 2400bps modems
> > were state of the art.
> 
> Good example. Modems got faster and faster and then, at 56kbps, 
> development hist a brick wall.

An economic one, yeah. ISDN, then DSL. Faster and cheaper. And
bandwidth on POTS was fixed. Computing power isn't.

> > Who cares?
> 
> The people who design and build routers and the people who
> pay for those routers.

I haven't seen any vendor rep warning about PI yet. My conclusion is
that they are confident to be able to build what we need.

Guys, we're talking about a couple 10k prefixes for the forseeable
future, at best.


Best regards,
Daniel

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