Ralph, > Responses in line... > > One key question I forgot to ask: text such as "Assigned prefixes are not > included in and do not include other assigned prefixes" implies to me that > the assignment algorithm accommodates assigned prefixes other than /64. If I > have that right, I think it would be useful to state that property explicitly. > > Another new question about this text in section 4.1: > > Best Assignment: For a given Delegated Prefix and Link, the Best > Assignment is (if any) the Advertised Prefix: > > * Including or included in the Delegated Prefix. > > How can an Advertised Prefix include the Delegated Prefix ... except, > perhaps, in the corner case that they are equal?
Well, there are even more cornered cases. Imagine you have a /56 DP, and you assign a /60. And suddenly the /56 DP dies and is replace by a single /64. Then you may have the assigned /60 containing the /64 DP. The node assigning the /60 *will* un-assign it as soon as it gets the information that the /56 died. But in the meantime, other nodes should wait before assigning a prefix from the /60. > > >> On Mar 18, 2015, at 4:04 AM 3/18/15, Pierre Pfister >> <pierre.pfis...@darou.fr> wrote: >> >> Hello Ralph, >> >> Thanks for your comments. >> >>> Here are my last call comments on draft-ietf-homenet-prefix-assignment: >>> >>> "implementing reliable broadcast" seems like an imprecise specification of >>> "Flooding Mechanism". Exactly what characteristics are desired for the >>> Flooding Mechanism: reliable delivery of the state of "published Assigned >>> Prefixes" within some time limit? >> >> I also believe ‘Reliable Broadcast’ does not help understanding what the >> flooding mechanism is. >> What about this definition ? >> OLD: A mechanism implementing reliable broadcast and used to advertise >> published Assigned Prefixes. >> NEW: A Mechanism allowing participating nodes to share information with all >> other participating nodes. > > Your new text has dropped the requirement for reliability. Is that OK? I actually noticed that right after sending the email. Good point. I added it. > >>> Might seem like a nit ... but what is a "node"? Always a router? Can it >>> be a host? Is it some abstract function that can appear in either a host >>> or a router? >> >> Any device implementing the algorithm. May be a host, a router, a human... I >> mean, the algorithm is not specific to IP, so it may be anything. > > For completeness, I suggest adding that definition to the "Terminology" > section. I take good note of that. Will add it if I got other similar comments. >> >>> >>> Editorial: in the definition of Private Link, "requesting router" would be >>> a better term than "client" (see RFC 3633). >> >> Good point. Thanks. >> >>> >>> Are Shared Links identified in some way in the mechanism? If so, how? I >>> see the phrase "there never is more than one Assigned Prefix per Delegated >>> Prefix and Link pair", but I don't see how a Link is identified. >>> Similarly, "The Assigned Prefix is advertised through the Flooding >>> Mechanism as assigned to its associated Link" Or maybe I'm missing >>> something and the identification isn't necessary? >>> >> >> It is necessary, but out of the scope of the document. > > Do you mean the exact way in which the identification is accomplished? Yes. There could be so many ways that can be done. Not relying on unique link identifiers. > >> Because it strongly relies on the context, e.g., whether links are numbered >> or not, or the type of messaging. >> For instance, in HNCP, we use a 32bits integer to identify node's >> interfaces. HNCP then uses neighboring information to know if a prefix is >> assigned on a directly connected interface, and if so on which one. > > For completeness, I suggest adding text to the effect that "each Shared Link > must have a unique identifier and all nodes must agree on the way in which > Shared Links are identified". It is not how it works in HNCP. In HNCP, we identify interfaces, not links. So links don’t have unique identifiers. We use interface identifiers and neighboring relationships in order to identify links. HNCP digests the information and gives it to the PA code. At that point, the link is identified by its position in memory (pointer). So there is no strong need for unique link identifier. Thanks, - Pierre _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
