Re: [homenet] prefix-assignment-03 [Reminder - WG Actions]

[Brian E Carpenter]

Pierre,

On 13/03/2015 20:33, Pierre Pfister wrote:
> Hello Brian,
> 
>>> Please note that there’s only just under a week left on the WGLC for 
>>> draft-ietf-homenet-prefix-assignment-03.
>>
>> I find myself wondering how this algorithm will work during a 
>> make-before-break
>> renumbering procedure. Maybe it's obvious (but not to me ;-).
> 
> In that case you would receive a new prefix not colliding with the previous 
> one.
> In the prefix assignment perspective, this new prefix is just a new delegated 
> prefix
> you should use for numbering you links. So the algorithm would use both and 
> you’d get one prefix
> per link for each of them. When the previous prefix gets removed, old 
> assigned prefixes 
> are removed too.

OK. It just wasn't obvious to me that PA could be used in that way.

> 
> PA is just a general purpose distributed numbering algorithm. The way you 
> handle lifetimes is out
> of the scope of PA. But it surely is in the scope of HNCP (ietf-homenet-hncp).
> 
> HNCP attaches the preferred and valid lifetimes to each delegated prefix, 
> which are in turn provided to the hosts by the
> mean of RAs.
> In the make-before-break case, PA numbers the links with the new prefix 
> before removing the prefixes associated with the old one.
> It let hosts renumber gracefully based on preferred lifetime values.

Right. So the next question is: what will trigger HNCP to start this
process? RFC 4192 seems to assume a guiding intelligence performing a
careful sequence of actions.

Thanks
Brian

> 
> 
> Cheers,
> 
> - Pierre
> 
> 
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-prefix-assignment-03.txt

[Ray Hunter]

Steven Barth 
12 March 2015 18:11


I have read this draft. It looks very good.
I agree (having reviewed probably all the various iterations of that 
document).




I have the following questions:

1. What are the interoperability considerations if the node also 
contains (historical) configuration for acting as an RFC7084 router?


Especially with respect to requirement L2 and L8.
I think that is more of an implementation matter not so much 
draft-relevant. I mean sure if you design your OS from the ground up 
with that in mind that would be easy. However in the reference 
implementation we deliberately do not do that as that would require 
emulating a lot of OS-specific behavior.


You can however replicate this configuration by defining the interface 
as hnet with mode=leaf (i.e. always internal, not connected to routers 
= doesn't speak RP nor HNCP on it) and you can give hnet a hint on 
what size and or id of the prefix you want to have assigned.


As for L8 (running DHCPv6) hncp-04 has similar requirements, DHCPv6 
behavior was at some point actually in the PA draft but it was moved 
to hncp I suppose for clarity reasons though Pierre could probably 
talk about this in more detail.





2. may/should/must a Homenet router that participates in the 
draft-ietf-homenet-prefix-assignment-03.txt also act as a proxy for 
an old RFC7084 router connected to one interface?
This - as well - is defined in hncp-04 instead and we do this in the 
reference implementation. Internally the delegating router announces 
the DP on behalf of the legacy router using HNCP and inserts a local 
route.




Cheers,

Steven


I've just been testing this feature, which is why I asked ;)

/56 was requested by hnet router to ISP router.

/62 was (correctly) allocated to the 7084 router by the hnet router.
route to /62was (correctly) advertised by the hnet router into Homenet.

Is it not worth adding a couple of sentences to this draft?

At the end of Section 6:

Proxy:   A proxy node is capable of acting on behalf of one or more 
non-participating device(s) (e.g. a downstream RFC7084 compliant router) 
in order to assign new prefixes, adopting, existing ones, making 
overriding assignments and destroying existing ones on behalf of the 
non-participating device(s). The exact mechanism to be deployed is 
outside the scope of this draft. The proxy node SHOULD ensure that any 
underlying topology discovery mechanism is stable and complete, before 
acting as a proxy node, to avoid causing any race conditions. The proxy 
node SHOULD also check that the network topology beyond the proxy node 
is single attached to the set of participating nodes.


--
Regards,
RayH

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] prefix-assignment-03

[Mikael Abrahamsson]

Hi, I am reading the document and typing as I go along:

I do not know what a "disjoint" delegated prefix is. When googling, 
"disjoint" seems to be a computer science term. Does it warrant 
explanation in the document?


"Flooding mechanism", the description of that seems very specific? 
Shouldn't it be about synchronizing information between the nodes instead 
of talking about "reliable broadcast"?


I have now spent 30 minutes trying to grasp how the state machine works. I 
don't know exactly why, but it's really hard, and it's hard to understand 
why some of the wording was chosen the way they were. "Best Prefix" is 
confusing when I at the same time read about "Current Assignment". Perhaps 
some text explaining the rationale for the choice of words and why they 
are needed, ie not only describing what needs to be done, but also why. 
"case study" or "state study" is perhaps what I'm looking for. I think I 
understand what's going on, but having some concrete examples would help.


Another thing: If I know that I will receive 3 /56:es from my ISP, and I 
always want $LINK to use the $56PREFIX02::/64 for all delegated prefixes, 
I believe this is possible within the current algorithm, but it's not 
specifically stated. It's stated that manually chosen prefixes can be 
done, but not examples of how these might be chosen. I know this example 
from cisco: 
http://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113141-DHCPv6-00.html


Here you can set "ipv6 address prefix-from-provider ::1:0:0:0:1/64" to 
achieve what I just described. In case of multiple delegated /56:es, some 
users might prefer that the same number subnet is chosen from all 
delegated prefixes.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix-assignment-03 [Reminder - WG Actions]

[Pierre Pfister]

Hello Brian,

>> Please note that there’s only just under a week left on the WGLC for 
>> draft-ietf-homenet-prefix-assignment-03.
> 
> I find myself wondering how this algorithm will work during a 
> make-before-break
> renumbering procedure. Maybe it's obvious (but not to me ;-).

In that case you would receive a new prefix not colliding with the previous one.
In the prefix assignment perspective, this new prefix is just a new delegated 
prefix
you should use for numbering you links. So the algorithm would use both and 
you’d get one prefix
per link for each of them. When the previous prefix gets removed, old assigned 
prefixes 
are removed too.

PA is just a general purpose distributed numbering algorithm. The way you 
handle lifetimes is out
of the scope of PA. But it surely is in the scope of HNCP (ietf-homenet-hncp).

HNCP attaches the preferred and valid lifetimes to each delegated prefix, which 
are in turn provided to the hosts by the
mean of RAs.
In the make-before-break case, PA numbers the links with the new prefix before 
removing the prefixes associated with the old one.
It let hosts renumber gracefully based on preferred lifetime values.


Cheers,

- Pierre
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix-assignment-03 [Reminder - WG Actions]

[Pierre Pfister]

Hello Brian,

>> Please note that there’s only just under a week left on the WGLC for 
>> draft-ietf-homenet-prefix-assignment-03.
> 
> I find myself wondering how this algorithm will work during a 
> make-before-break
> renumbering procedure. Maybe it's obvious (but not to me ;-).

In that case you would receive a new prefix not colliding with the previous one.
In the prefix assignment perspective, this new prefix is just a new delegated 
prefix
you should use for numbering you links. So the algorithm would use both and 
you’d get one prefix
per link for each of them. When the previous prefix gets removed, old assigned 
prefixes 
are removed too.

PA is just a general purpose distributed numbering algorithm. The way you 
handle lifetimes is out
of the scope of PA. But it surely is in the scope of HNCP (ietf-homenet-hncp).

HNCP attaches the preferred and valid lifetimes to each delegated prefix, which 
are in turn provided to the hosts by the
mean of RAs.
In the make-before-break case, PA numbers the links with the new prefix before 
removing the prefixes associated with the old one.
It let hosts renumber gracefully based on preferred lifetime values.


Cheers,

- Pierre


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet