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

[Brian E Carpenter <[e-mail]>]

Pierre,

On 10/11/2014 16:33, Pierre Pfister wrote:
> Thank you Brian for your review.
> 
> See my answers inline.

Thanks, I will just comment where there is something open:

...
>>>   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.

There is the term 'Zone ID' used in RFC 4007 and 6874, but that is possibly
even more confusing. However, it is what we have and there is even URL syntax
for it.

> 
...

>>>   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.

Yes, certainly if you "kill" an IPv6 address without going through normal
deprecation that needs to be clearly stated.

> 
>> ...
>>>   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 ?

No, I have to read HNCP again soon and then I will be back if I
don't understand.

>>> 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 ?

Not in a homenet, no, but this restriction will not apply in anima, I think.

...

>>> 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.

Right, do you want to specify a minimum size v4 subnet, or just leave it open?


>>> 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 ?

Not really, I just think you should suggest a recommended value.

...
>>>   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 ?

Well, I think I understand, but actually naming the routers avoids all doubt.

> 
>>>   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.

OK, but I think it does no harm to be very clear when you refer to the
whole /48 and when you refer to a specific subnet prefix. I'm sure it's clear
in your mind.

Regards
   Brian