[homenet] some comments on baker-homenet-prefix-assignment

Michael Richardson <mcr@sandelman.ca> Tue, 17 January 2012 01:29 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E2921F85E4 for <homenet@ietfa.amsl.com>; Mon, 16 Jan 2012 17:29:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.011
X-Spam-Level:
X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[AWL=-1.316, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, SARE_MONEYTERMS=0.681]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qos8RygbXr6v for <homenet@ietfa.amsl.com>; Mon, 16 Jan 2012 17:29:10 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id CEAB921F85AA for <homenet@ietf.org>; Mon, 16 Jan 2012 17:29:10 -0800 (PST)
Received: from marajade.sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id C3CBE3446F for <homenet@ietf.org>; Mon, 16 Jan 2012 20:27:07 -0500 (EST)
Received: by marajade.sandelman.ca (Postfix, from userid 179) id 739809845D; Mon, 16 Jan 2012 20:29:08 -0500 (EST)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 6ED0A98147 for <homenet@ietf.org>; Mon, 16 Jan 2012 20:29:08 -0500 (EST)
From: Michael Richardson <mcr@sandelman.ca>
To: homenet@ietf.org
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 16 Jan 2012 20:29:08 -0500
Message-ID: <9482.1326763748@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: [homenet] some comments on baker-homenet-prefix-assignment
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 17 Jan 2012 01:29:11 -0000

I finally read draft-baker-homenet-prefix-assignment on my way home on Friday. 
This mechanism is that I had expected that we would use.  I agree that 
draft-arkko-homenet-prefix-assignment-01 might take fewer messages and
less code.

I had a few minor comments which are appended below, but I had two
general questions. 

First, I think that the RAAI option first describe in section 3.1.1 is a
new creation; certainly by the IANA considerations, that is clear, but
at first I thought maybe that this was yet-another-RA-option I did not
know about...   Section 5 gives the abstract for what I think is a new
option.  Should this concept go forward, I suggest that the name of this
option go into the title of the document, as in:
       Using the Router Advertisement Allocator Information (RAAI)
       for subnet allocation in Home Networks.

Second, the process by which the two routers in section 3.1.2.2 hear
each other and release the prefix was a bit startling!   It wasn't until
the last paragraph of 4.3 that some addition to the algorithm is mentioned.

minor comments:
1. To avoid duplicate address assignment, a router first listens for RAs
   on the link attached to its downstream interface.  If the router does
   not receive an RA after listening for INTERVAL1 microfortnights, the

Assuming that my calculation is correct, and microfortnights are
approximately 1.2s, my feeling is that this dead time should be on the
order of 16 microfortnights (20s).  I base this number upon the time it would
take me to replace my home router back on the shelf after rebooting it,
then walk back to the kitchen table, and check to see if my laptop got
an address.   Another 10s later, I'm back at the router to wonder if it
really rebooted again.

2. why doesn't a router send a RS on the link first? Given multiple
   ISPs, it may be entirely reasonable that the interface is in fact
   downstream for another prefix, and an upstream interface for another,
   so the RS isn't even wasted. 

3. a link would seem to be unclaimed if (a/one or more) RS is heard on
   the link, and no RA is later heard.  As I recall, RAs in response to RS
   may be unicast, but, why can't the router in question send it's own
   RS to verify connectivity.
   Here is where the zOSPFv3 method may be more productive.

4. It seems that an ISP might well return a RAAI to a client machine,
   and if it did so, it could allocate as many or as few /64s as each
   customer needs, at the cost for it, of additional routing entries.

   I realize that this might be undesireable from an architectural point
   of view, but I can see occuring in some informal multi-tenant
   situations, where the "building" starts initially as a single tenant,
   and grows.  As such, it may be useful to put a flag in the RAAI that
   says, "I am a security boundary".

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.