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
- [homenet] I-D Action: draft-ietf-homenet-prefix-a… internet-drafts
- Re: [homenet] I-D Action: draft-ietf-homenet-pref… Brian E Carpenter
- Re: [homenet] I-D Action: draft-ietf-homenet-pref… Pierre Pfister
- Re: [homenet] I-D Action: draft-ietf-homenet-pref… Pierre Pfister
- Re: [homenet] I-D Action: draft-ietf-homenet-pref… Brian E Carpenter