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?
> On Mar 18, 2015, at 4:04 AM 3/18/15, Pierre Pfister <[email protected]>
> 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?
>> 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.
>
>>
>> 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?
> 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".
>
> Thanks,
>
> - Pierre
>
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
