Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

[Alexandru Petrescu <[e-mail]>]

Hi Pierre,

Le 08/10/2014 13:28, Pierre Pfister a écrit :
> Hi Alex,
>
> Reply is inlined,
>
> Le 8 oct. 2014 à 12:09, Alexandru Petrescu
> <[e-mail]> a écrit :
>
>> Hi Pierre,
>>
>> Thanks for the draft update.  Now I have two questions:
>>
>>> prefixes of size 64 are RECOMMENDED.
>>
>> Why is this length recommended?  I think it may be because of
>> Ethernet?
>
> I’m not a big fan of putting 64s everywhere neither. And I strongly
> disagree with mandating 64 bit long prefixes. The prefix algorithm
> itself is agnostic on this side.
>
> Nevertheless, some parts of this document are home-network specific.
> Not even talking about crappy implementations, home network links
> should support SLAAC whenever possible. Which is the reason why using
> 64bit long prefixes is RECOMMENDED.

Ah, I see.  I doubt though SLAAC is 64.  Maybe Ethernet is.

> But smaller prefixes are better than *no prefix at all*. When there
> are not enough prefixes available (e.g. the ISP provides a single 64
> while we have multiple links), smaller prefixes can be used (80 for
> instance). Which means dhcpv6 must be used. Our implementation
> supports it, and it works with my laptop.

Ok.

> But again, that should be avoided whenever possible. And ISPs MUST
> provided enough prefixes (IMO).

I agree with you.

Last time I checked Free ISP seems to provide 8 /64 prefixes to my homenet:
2001:db8:0:ce10::/64
2001:db8:0:ce11::/64
...
2001:db8:0:ce17::/64
I dont think these could be aggregated into a single shorter prefix, or 
my math is missing.

Second, their (Free's) web interface asks me to put a next hop for each 
of these prefixes.

Do you think HNCP implementation may help fill in these fields 
automatically somehow?


>> Maybe it would be advantageous to not make any recommendation on
>> the prefix length.  Some times this may develop into a barrier
>> beyond which it will be hard to go.
>>
>> The other question is about the assumed capability to decide non
>> between prefixes, such as to detect collisions.  Do you think it is
>> possible to decide equality between prefixes?  I rather think
>> prefixes have a more refined relationship than just equal/not-equal
>> - e.g. they are also aggregated.
>>
>> If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do
>> you think a 'collision' could be detected?  I doubt we have such an
>> algorithm somewhere.
>>
>
> Equality is never considered alone. Actually, most of the time, you
> will find considerations such as: The prefix is not included or does
> not include any other Assigned Prefix with a higher precedence.

I wonder about the implementability of this statement, but yes it may be 
possible to write one.

> This is how collisions are detected.

Ok.

Alex

>
> Cheers,
>
> - Pierre
>
>
>> Alex
>>
>>
>>
>> Le 30/06/2014 17:18, Pierre Pfister a écrit :
>>> Hello group,
>>>
>>> I’d like to inform you about the changes made in the two last
>>> homenet-prefix-assignment updates.
>>>
>>> http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02
>>>
>>>
>>>
The changes are mostly about fixing typos, but a few technical changes 
have been made as well (based on the experience gained from the 
implementation of the Prefix Assignment Algorithm over HNCP).
>>>
>>>
>>> — Changes between 00 and 01
>>>
>>> - If a Delegated Prefix is included in another Delegated Prefix,
>>> it is ignored. This is intended to improve support for
>>> non-homenet routers that provide prefix sub-delegation. That way,
>>> sub-delegated prefixes are ignored.
>>>
>>> - Adding network leader definition (The router with the highest
>>> identifier).
>>>
>>> - Add a section about DHCPv6 downstream prefix delegation. For
>>> downstream RFC7084 routers support.
>>>
>>> - Adding Delegated Prefix deprecation procedure in order to
>>> differentiate prefix deprecation and node disconnection. When a
>>> node disconnect, the DPs advertised by this node may be kept some
>>> time (depending on the DP's lifetimes). But if a DP is actively
>>> deprecated, nodes must stop using it immediately.
>>>
>>>
>>> — Changes between 01 and 02
>>>
>>> - Designated router election can make use of the information
>>> provided by the flooding protocol (i.e. when no router is
>>> designated yet, only the highest router id present on the link
>>> can become designated).
>>>
>>> - New implementation guideline in appendix concerning "prefix
>>> waste avoidance". It proposes an algorithm that provides a good
>>> trade-of between randomness, pseudo-randomness and prefix
>>> selection efficiency.
>>>
>>>
>>>
>>> Comments are welcome,
>>>
>>> Pierre Pfister _______________________________________________
>>> homenet mailing list [e-mail]
>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>>>
>>
>>
>> _______________________________________________ homenet mailing
>> list [e-mail]
>> https://www.ietf.org/mailman/listinfo/homenet
>
>
>