Re: [v6ops] new draft: draft-ietf-v6ops-cidr-prefix

[Nick Hilliard <[e-mail]>]

On 12/02/2015 23:59, Lorenzo Colitti wrote:
> Reality dictates that routing on 128 bits consumes more resources than
> routing on 64 bits. Attempting to enforce that all routing table entries
> must be full 128 bits wide will either result in the hardware supporting
> fewer routing table entries or in the hardware costing more, neither of
> which to anyone's gain.

the concern people have is that if you end up with hardware which
effectively dictates /64 due to lpm optimisation constraints, this will
make it really troublesome to use other prefix lengths.  This might or
might not be ok for individual boxes with a couple of connected /64s, but
once you link this into a routing domain it can cause serious trouble.

E.g. in the case of the N5K previously quoted, 16k ipv4 entries makes it a
fine box for certain types of ipv4 edge deployment, but the limit of 128
longest prefix match entries for ipv6 means that it's impossible to hook
this into an ipv6 IGP routing domain, which means that from a generic ipv6
l3 deployment point of view, the box is nearly useless.

>From this point of view, it may be useful to have an RFC to say to vendors
"please don't do this because it is actively harmful".

Otherwise everyone acknowledges that there is a balance to be drawn between
cost and scalability.  Maybe this balance could be made more explicit in
the draft.

Nick