Subject: [homenet] draft-gmann-homenet-relay-autoconf-

From: Michael Richardson <[email-masked]>
Date: Mon, 07 May 2012 15:27:15 -0400

I read this document just now.
What I understand is that level-2+ routers go to "the" ISP to get an
additional /64.  The ISP could return anything... it might be good if it
returned a /64 adjacent to those already assigned, but it can do
anything.  The ISP->customers assignments are not aggregated.

This has interesting properties for efficient use of address space, and
also for permitting home networks to be as big or small as desired.

There is really no additional overhead in the homenet, as one is likely
throwing /64 routes around most of the time anyway.  For the ISP, it's
up to them.

My only problem is that I don't understand how it works when you have
two ISPs.

- -- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 May 2012 07:49:31 +0100

On 2012-05-07 20:27, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 

Not *necessarily* aggregated. I would have thought aggregation remains
valuable.
> also for permitting home networks to be as big or small as desired.

Efficiency at the level of filling /56s really isn't a worry, is it?
It would just be simpler to allocate each subscriber a /56.

> My only problem is that I don't understand how it works when you have

I think both of these assumptions will be false for a substantial fraction
of subscribers:

   This document assumes that the vast majority of home networks will
   connect to a single ISP and will be generally constructed in a tree
   architecture.

      Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 May 2012 08:03:53 -0400

>>>>> "Brian" == Brian E Carpenter <Brian> writes:
    >> I read this document just now.  What I understand is that
    >> level-2+ routers go to "the" ISP to get an additional /64.  The
    >> ISP could return anything... it might be good if it returned a
    >> /64 adjacent to those already assigned, but it can do anything.
    >> The ISP->customers assignments are not aggregated.

    Brian> Not *necessarily* aggregated. I would have thought
    Brian> aggregation remains valuable.

Let me say:
    The ISP->customers assignments are not aggregated by the customer.

If the ISP aggregates it, great.

    >> This has interesting properties for efficient use of address
    >> space, and also for permitting home networks to be as big or
    >> small as desired.

    Brian> Efficiency at the level of filling /56s really isn't a worry,
    Brian> is it?  It would just be simpler to allocate each subscriber
    Brian> a /56.

I agree, but it's now up to the ISP.

    >> There is really no additional overhead in the homenet, as one is
    >> likely throwing /64 routes around most of the time anyway.  For
    >> the ISP, it's up to them.
    >> 
    >> My only problem is that I don't understand how it works when you
    >> have two ISPs.

    Brian> I think both of these assumptions will be false for a
    Brian> substantial fraction of subscribers:

    Brian>    This document assumes that the vast majority of home
    Brian> networks will connect to a single ISP and will be generally
    Brian> constructed in a tree architecture.

I agree; it's not a good assumption.

I'd rather see the DHCP PD be proxied (rather than snooped) by the
border router(s).  I think that draft-baker-homenet-prefix-assignment
basically does this, but manages the prefixes locally.

So, if we agreed that having the ISP delegate /64s as needed was the
right answer, then draft-baker-homenet-prefix would solve the problem.

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