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

[Ole Troan <[e-mail]>]

Pierre, Alex,

please make sure this document does comply with http://datatracker.ietf.org/doc/draft-ietf-6man-why64/
while I think the algorithm and data formats should support any prefix lengths, I don't think the sections dealing with "what if we've run out of prefixes" should be included in this document.

cheers,
Ole


> On 08 Oct 2014, at 13:28 , Pierre Pfister <[e-mail]> wrote:
> 
> 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.
> 
> 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.
> 
> But again, that should be avoided whenever possible. And ISPs MUST provided enough prefixes (IMO).
> 
>> 
>> 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.
> 
> This is how collisions are detected.
> 
> 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
> 
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet