Thank you Brian for your review. See my answers inline.
> Hi, > > A few somewhat random comments: > > Everywhere you refer to "small" and "smaller" prefixes. > This is confusing. I assume you mean "long" and "longer ». I guess it’s legitimate. Prefix ‘size’ doesn’t exist, but ‘length’ does. It will get fixed. > >> 4.1. Data structures > ... >> Router ID: The identifier of the advertising router. > > Who assigns this? I think you mention that later but here > it's just a dangling reference. There are multiple references of Router ID before it is defined. I should probably add a terminology section. > >> >> Link ID: If the assignment is made on a connected link, an interface >> identifier of the interface connected to that link. > > That's a bit confusing because a link is not an interface, and the same > link connected to multiple interfaces will have multiple Link IDs > by this definition. Also, you can't call it Interface ID because that > has a specific meaning in IPv6. I don't have a good suggestion but > it needs to be tidied up IMHO. I agree. But as ‘interface ID’ can’t be used, I wonder what could be best. > >> 4.2. Routers' Interfaces >> >> Each interface MUST either be considered as internal or external. >> Prefixes and addresses are only assigned to internal interfaces. The >> criteria to make this distinction are out of the scope of this >> document. > > By "criteria" do you mean mechanisms? That seems to be a discovery > problem (and it also occurs during security bootstrapping). But > I think you really need to define what internal and external *means*. > The words are not self-defining. It is a homenet specific consideration, and is indeed a bootstrapping+configuration problem. I wonder if I shouldn’t separate what is homenet-specific from what is Prefix-Assignment generic. In the prefix assignment context, what ‘internal’ vs ‘external’ means is ‘enabled’ or ‘disabled’ for prefix assignment. Which is why it is not defined in this document. I take good note though and will probably remove that terminology, or rephrase it. Internal Vs External is explained in other documents. > >> If an internal interface becomes external, all prefixes and addresses >> assigned on the considered interface MUST be deleted... > > Yes but... they can't be dropped instantly; at least for v6 they have > to go through the deprecation phase, surely? IMHO, they should be dropped instantly. Because if you start considering a link as external, it means you realized that you have absolutely no right to be a default router on that link. At best, you do something that you shouldn’t do. At worst, the uplink router may kill the port you are connected on. I agree I could clarify though. > > ... >> Whenever two or more interfaces are connected to the same link, > > How is this known to be the case? I imagine a little TV camera > peeping out from the router to look at the cables… In the same paragraph: A mechanism to detect such situation SHOULD be provided by the flooding algorithm. Do you think I should rephrase somehow ? > >> 4.5. Designated Router >> >> On a link where custom host configuration must be provided, or >> whenever SLAAC cannot be used, a DHCP server must be elected. That >> router is called designated router and is dynamically chosen by the >> prefix assignment algorithm. > > You are assuming without stating it that the DHCP server MUST be located > in the same device as a router. Why? In a homenet context, I think it makes sense. Doing it differently would probably increase the algorithm complexity. Now, you’re probably suggesting that, in other scenarios, it may be different ? Do you have a use-case in mind so it would make sense to make it differently ? > > Is the designated router the same one for v4 and v6, and if so, why? Yes. Because the algorithm is agnostic (as much as it can be). > >> 4.5.1. Sending Router Advertisement >> > ... >> The designated router MUST advertise itself as a router for all IPv6 >> delegated prefixes using Route Information Options [RFC4191], >> independently of whether there is a default route or not. > > Why? Maybe different MIF PVDs should be handled by different routers, > if some form of SADR is supported. Because their can only be a single DHCP server on some link, different MIF PVDs will need to be provided by a single router as well. Which is fine. At worse, hosts will send packets to the wrong router, but that router will use Source-Specific-Routing to send it back to the right router (or send a redirect). > >> 6.6. Making a New Assignment > ... >> When the algorithm decides to make a new assignment, it first needs >> to specify the desired size of the assigned prefix. Although this >> algorithm intends to remain generic, the use of 64 bits long prefixes >> is RECOMMENDED (See [I-D.ietf-6man-why64]). > > And for v4? Hard to fulfill that recommandation with v4. ;) I found it pretty clear that it doesn’t apply to v4. But right. I will patch that for next version. > >> 6.10. Downstream DHCPv6 Prefix Delegation support > ... > >> If DHCPv6 Reconfigure is >> not supported, leases lifetimes SHOULD be significantly small. > > Can't parse "significantly". Can you quantify this? 2h ? Do you have a proposal ? > >> 9.1.1. Choosing the ULA prefix >> >> When a stable ULA prefix is advertised, all routers SHOULD remember >> that prefix alongwith its associated valid and preferred lifetime. >> If this prefix stops being advertised (e.g. due to a network split) >> while its preferred lifetime is not null, the same ULA prefix SHOULD >> be selected using the same valid and preferred lifetimes. > > What is doing the selecting? This is a case where the passive tense is > confusing. I will try to clarify. Moving to active form. > >> 9.1.2. Advertising a ULA prefix >> >> A router MAY start advertising a ULA prefix whenever the two >> following conditions are met: >> >> o It is the network leader. >> >> o There is no other advertised ULA prefix. >> >> If no IPv6 prefix is available at all, the network leader SHOULD >> start advertising a ULA delegated prefix. > > Do these two bullets refer to the same thing (a complete ULA /48) or > to longer ULA prefixes? That is a ULA spontaneously generated ULA delegated prefix. So that is a /48. I will clarify in next version. > >> >> Additionaly, a router SHOULD start advertising its own ULA prefix >> whenever the three following conditions are met: >> >> o A stable ULA prefix is advertised by another router. >> >> o The router owns the advertised stable ULA prefix. > > I got confused about which router is which. Could you give > them names, e.g. > > Additionaly, a router "A" SHOULD start advertising its own ULA prefix > whenever the three following conditions are met: > > o A stable ULA prefix is advertised by another router "B". > > o The router "A" owns the advertised stable ULA prefix. > > And then it still doesn't make sense to me (and again I'm asking > whether we are talking about a /48 or something longer). There are only two routers. One is ‘the router’. The other is ‘another router’. Is it *that* unclear ? > >> A router MUST stop advertising a spontaenously generated ULA prefix >> whenever one of the two following condition is met: >> >> o A different ULA prefix is being advertised. >> >> o The same prefix is advertised by another router, and the router >> doesn't own that prefix. > > Here too I am confused about which router is which and which prefix > length is involved. There is no prefix length involved there. > > That's it for now. > > Brian Thank you very much for your comments ! I’m sorry I have no time to work on proposals right now but I hope I answered your question. As for the clarification needed, I will work on that point by point and rephrase where it is needed. See you tomorrow at Anima’s meeting. - Pierre > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
