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

Pierre Pfister <pierre@darou.fr> Mon, 10 November 2014 03:33 UTC

Return-Path: <pierre@darou.fr>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AE51A88D0 for <homenet@ietfa.amsl.com>; Sun, 9 Nov 2014 19:33:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.94
X-Spam-Level:
X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulKsqjVtUvn9 for <homenet@ietfa.amsl.com>; Sun, 9 Nov 2014 19:33:35 -0800 (PST)
Received: from ks395963.kimsufi.com (darou.fr [176.31.121.140]) by ietfa.amsl.com (Postfix) with ESMTP id 29F5E1A88C7 for <homenet@ietf.org>; Sun, 9 Nov 2014 19:33:35 -0800 (PST)
Received: from [172.20.1.167] (unknown [64.129.1.5]) (Authenticated sender: pierre@darou.fr) by ks395963.kimsufi.com (Postfix) with ESMTPSA id 0458E603B0; Mon, 10 Nov 2014 04:33:31 +0100 (CET)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D6733E6B-086A-4DAD-9140-9EE9278546E3"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pierre Pfister <pierre@darou.fr>
In-Reply-To: <545FD1CA.8060202@gmail.com>
Date: Sun, 09 Nov 2014 17:33:27 -1000
Message-Id: <260A8AA1-A87E-461A-9150-A88DA4A05110@darou.fr>
References: <20141024121633.26839.23922.idtracker@ietfa.amsl.com> <545FD1CA.8060202@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/4SjMpVcsZakr8miS8sv_YZcNEXY
X-Mailman-Approved-At: Mon, 10 Nov 2014 11:07:32 -0800
Cc: homenet@ietf.org
Subject: Re: [homenet] I-D Action: draft-ietf-homenet-prefix-assignment-01.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 03:33:43 -0000

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
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet