[ipv6-wg] 96 more bits... time for some magic after all?

Hello,

first of all thanks a lot for the feedback.

On 10/27/2013 01:15 PM, S.P.Zeidler wrote:
> Thus wrote Yannis Nikolopoulos (dez at otenet.gr):
>
> [snip]
>> Should we go on and produce a BCP
>> document of some kind? As the author of this addressing plan
>>
>> (https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf) , my main motivation for presenting it was to show that it is possible to encode basic information in an addressing plan (without wasting too much space) and still keep it simple . For example, even IPv4 addressing plans were location-aware, that's nothing new. Well, its even easier and more effective in IPv6 addressing, because of the number of bits available. As far as encoding service type, no space is wasted because it is encoded after the /56 boundary ;) , even making it possible for QOS.
> Ok, let me be less terse. I'm not speaking from a scientific research
> position but from a gut reaction which is based on some practical
> experience.
>
> [...]
> If your network equipment does not use the encoded information,
> thus making errors obvious by causing failures, you can expect that
> the information encoded is a cute note but not a reliable one.
> There's nothing wrong with conventions, especially if they are
> entertaining, as long as you remember that that's all they are, and that
> they can be put out with the garbage if there is a good reason.

i agree, it's happened way too many times in the past...

> For a network plan I have been involved in, for an ISP with many
> locations and expecting growth, we basically said:
>
> We have small, medium, large and huge locations.

we've been down that road a few times (with both v4 and v6) but decided 
against it in the current plan.

> [...]
> Regarding the addressing plan you made: I don't know your network, you do.
> My comments may thus simply not apply because of local conditions.
> So, adding this packet of salt:
>
> Not to be snide, but "trusted" is a bad designation :) You know all the
> jokes about the evil bit? Being able to immediately see that a fault
> is probably your issue is good, trusting large ranges of address space
> less so.

yep, I agree. We're not exactly using "trusted vs non-trusted", more 
like "infrastructure vs customers". Infrastructure is not all trusted of 
course ;)

> Traffic types in front of location prevents aggregation, which is not a
> huge issue these days, but still unnessecarily inefficient.

Actually, we're aiming at being efficient by aggregating customer 
prefixes which are smaller than /32

> That's also what I don't like about your loopback choice and transfer
> addresses choice; your routing table will contain quite a bunch of /128.
>
> Also, having both traffic type and service seems redundant (is there an
> issue for network ops to get prefixes configured in a local firewall?
> Otherwise I'd expect infrastructure to just be treated as another
> service), and lower than /56 you normally leave to your customers
> (a case of "local specialties not mentioned" that make you contol
> those bits as well?)

infrastructure being another service was considered and may actually be 
a better idea :) . About messing with bits 56-64 for customer services, 
I realise it sounds awkward but what we *might* do in the near future 
(when and if it makes sense) is to apply certain policies for certain 
groups of /64s and that's that.

>
> No quarrel with encoding the vlan id in the local infrastructure subnet
> as long as you agree beforehand to write numbers (hex) or strings;
> that's an example of convention. If you write string, the presence
> of a letter can mean it's not a vlan.
>
> Your plan of numbering residential customers up and business customers
> down will not survive contact with the enemy^Wcustomer unscathed; also
> its information content is limited as long as you don't know where the
> border is (and that will be different in every location, unless you are
> willing to accept large gaps that may not fill), but as a convention, why
> not.

I'm not sure I follow here :)

> I'm missing an explicit plan on how locations get grown. You assume you'll
> never run out with a /40?

on the contrary, we're expecting to run out. If that's the case, either 
a 2nd /40 (location) is allocated for the same PoP (e.g athens1, 
athens2) or the same location is used in the next "customer" /32

cheers,
Yannis
>
> regards,
> 	spz