Subject: [homenet] 2nd Working Group Last Call for draft-homenet-arch

From: Ray Bellis <[email-masked]>
Date: Mon, 3 Jun 2013 13:35:06 +0000

This email marks the commencement of the second Working Group Last Call for draft-ietf-homenet-arch-08.  The WGLC will end on Monday June 17th.

Please send your comments soonest, and in particular please check that any issues that you highlighted during the previous WGLC have been addressed.

Ray and Mark.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 14 Jun 2013 09:08:13 +0000

I'd like to remind the WG that this last call will expire *next Monday*.

Please send any comments to the list and editor ASAP.  It would also be useful to receive comments along the lines of "it's ready, ship it!".

thanks,

Ray

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 15 Jun 2013 14:35:01 -0400

> Please send any comments to the list and editor ASAP.  It would also be useful to receive comments along the lines of "it's ready, ship it!".

Hi Ray,

It is helpful if the draft name is spelled right in the WGLC.
draft-ietf-homenet-arch-08 but a search for homenet-arch is fine.

A lot of progress has been made in the last year or so.  Quite a few
issues remain open in that there is no solution recommended in
homenet-arch, or multiple solutions are recommended primarily because
downselection has not occurred.  Examples of the former is "routing
functionality" and service discovery beyond the subnet, and "domain
discovery".  Examples of the latter is address allocation, prefix
delegation.

BTW- Naming used to cite draft-mglt-homenet-naming-delegation and
draft-mglt-homenet-front-end-naming-delegation and I'm not sure why
those citations were dropped, unless they are now abandonned (they are
both expired).

The point is that though this framework has tremedously improved
(though it still cited mDNS and entertains the possibility of multiple
zeroconf name services plus DNS :), there is a ways to go.  Hopefully
this draft can remain a living document rather than freeze it
prematurely by moving it to the IESG and trying to get premature RFC
status.

On many issues the WG has converged in the last year or so, yet IMHO
too many remain open.

Curtis

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Jun 2013 06:51:19 +0200

> This email marks the commencement of the second Working Group Last
> Call for draft-ietf-homenet-arch-08.  The WGLC will end on Monday
> June 17th.

I've read this draft with great interest.  There's a lot about it that
I like.

Unfortunately, I've noticed one paragraph that I believe is wrong.  In
Section 3.5, you say:

   It is desirable that the routing protocol has knowledge of the
   homenet topology, which implies a link-state protocol is
   preferable.  This would mean the routing protocol gives
   a consistent view of the network, and that it can pass around more
   than just routing information.

This would seem to imply that only link-state protocols can "give
a consistent view of the network", and that only link-state protocols
can "pass around more than just routing information".  I'm pretty sure
BGP and EIGRP experts would disagree with that.

Is it too late to remove this paragraph?

-- Juliusz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 17 Jun 2013 09:26:42 +0200 (CEST)

> Please send your comments soonest, and in particular please check that any issues that you highlighted during the previous WGLC have been addressed.

So, I know I am late in the game, but I have re-read this document and 
have the following thoughts:

3.5.1.

It would perhaps be beneficial if there was some text regarding multicast 
traffic destined for devices within (and not outside, and thus shouldn't 
be forwarded to the USP) the home and what might be a future "Internet 
multicast", or at least some text that might indicate that multicast might 
be received from the ISP and that multicast is not just used *within* the 
home.

When I read the current text I am afraid some people might read it as 
multicast is only being used within the home and nothing else.

.

Apart from that, I believe that this text sums up most of the components 
needed for the high level goal "home network that can support multiple 
ISPs, organised in whatever way the customer connects the device, and 
which the user can connect to from whereever he is as long as he has 
proper Internet access". Perhaps there could be some text on IPSEC and key 
management, but I believe this is covered in the "discovery mechanisms" 
section where the document says it doesn't focus on this but just says 
this kind of communication should be possible.

So I support this document as being a useful arch document going forward.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Acee Lindem <[email-masked]>
Date: Mon, 17 Jun 2013 09:25:48 +0000

> Is it too late to remove this paragraph?

It is not too late to remove it but there is no reason to remove it. BGP is not used for constructing a topological view of the network and EIGPR isn't even an IETF protocol. 

Acee 

> 
> -- Juliusz
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Acee Lindem <[email-masked]>
Date: Mon, 17 Jun 2013 09:47:45 +0000

> It is not too late to remove it but there is no reason to remove it. BGP is not used for constructing a topological view of the network and EIGPR isn't even an IETF protocol. 

s/EIGPR/EIGRP/ 

Note that I'm making this statement as Routing Advisor to the the Homenet WG. The document is not saying that a link state protocol is the only way to satisfy the home network routing requirements, it is saying one is preferable. In my opinion, there are at least two reasons for this:

         1. Nearly everyone can understand how a link state protocol provides a consistent view of the network and meets the home network requirements. 
         2. There are two widely deployed IETF standard link state protocols. 

Thanks,
Acee

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Jun 2013 13:18:52 +0200

Thanks for your reply, Acee.

>          1. Nearly everyone can understand how a link state protocol
>          provides a consistent view of the network and meets the
>          home network requirements.

Granted, these are good reasons to promote OSPF.  However, these are
*not* the reasons given in the draft.

If these are the reasons why the Homenet group promotes a link-state
protocol, that's fine, but then this should be stated in the arch
document.  The paragraph as it is currently written is quite simply
incorrect, and should either be rewritten to reflect the correct
reasons or removed altogether.

-- Juliusz

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Jun 2013 13:49:03 +0200

> Is it too late to remove this paragraph?

why would BGP and EIGRP experts disagree with that?

cheers,
Ole

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Jun 2013 14:13:27 +0200

Hi Ole,

> why would BGP and EIGRP experts disagree with that?

BGP has an extensive attributes mechanism that allows it to "pass
around more than just routing information".

EIGRP has a number of mechanisms (reliable transport, active phase)
that ensure that it provides a "consistent view of the network" at all
times (arguably more so than multi-area OSPF).

The implication that only link-state protocols can have these
properties is incorrect.  This is completely orthogonal to the issue
of whether the Homenet group wishes to promote the use of OSPF.

-- Juliusz

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Jun 2013 14:17:35 +0200

Juliusz,

> of whether the Homenet group wishes to promote the use of OSPF.

hmm, is your argument above that you can build a link state routing protocol on top of EIGRP or BGP?

cheers,
Ole

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Jun 2013 14:26:46 +0200

> protocol on top of EIGRP or BGP?

No.  I said "consistent view", not "complete view".

Ole, Acee, I'm not arguing about whether there are good reasons to
promote link-state protocols for Homenet, which there might very well
be.  I'm just saying that the current formulation is technically
incorrect, and that it should, er, SHOULD be fixed before publication.

-- Juliusz

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Jun 2013 05:39:22 -0700

> incorrect, and that it should, er, SHOULD be fixed before publication.

I agree: there is no reason put out incorrect facts; it just makes it look like
the text is searching for a way to obtain the desired result, and weakens its case.

That is consistent with my detailed feedback regarding the 'desired result' of mdns
which as far as I can tell has never been resolved.

And the chairs can consider that my last call feedback: my feedback was ignored, not
rebutted, as far as I can tell. So what's the point of feedback/last call?

Mike

---

From: Ray Hunter <[email-masked]>
Date: Mon, 17 Jun 2013 14:49:15 +0200

I've read the 08 version.

It's not perfect, but I think it's good enough to achieve the stated
goal "to define a general architecture for IPv6-based home networking,
describing the associated principles, considerations and requirements"

Substantive comments

6204 and 6204 bis are silent of extension headers. There's been a flurry
of notes recently on 6vops and 6man on the level/lack of support for
extension headers. I tested my own IPv6 CPE and it doesn't seem to
transmit any packets containing a fragment header, regardless of whether
a firewall was configured or not.

Do we need any text on this item? Section 3.6.3?

Section 2.1 challenges of multiple subnets.

Do we need to add "Yet another challenge is how to handle mobile devices
that move around within the home and how they relate to the multiple
available prefixes."

Section 2.4 & Section 3.4.2

/A home network
   running IPv6 should deploy ULAs alongside its globally unique
   prefix(es) to allow stable communication between devices (on
   different subnets) within the homenet where that externally allocated
   globally unique prefix may change over time (e.g. due to renumbering
   within the subscriber's ISP) or where external connectivity may be
   temporarily unavailable.
/

I take issue with ULA being a SHOULD. MAY seems more appropriate given
the lack of operational experience and the last paragraph of the section.

regards,
RayH

---

From: Ray Bellis <[email-masked]>
Date: Mon, 17 Jun 2013 13:06:39 +0000

> rebutted, as far as I can tell. So what's the point of feedback/last call?

Looking back at my list archive I see substantial discussion, including notes from the document editor of changes made in response to your feedback .  You were clearly *not* ignored.

Could you please enumerate which specific concerns with the document that you raised during the last WGLC have not been addressed.

kind regards,

Ray

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Jun 2013 06:10:03 -0700

> Could you please enumerate which specific concerns with the document that you raised during the last WGLC have not been addressed.

As I recall, the document editor only addressed one and ignored most/all of the rest. I know
there was a lot of discussion (pro/con/many other pov's), just not by the editors which is why
I don't think the comments were coming from outer space.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jun 2013 09:15:27 -0400

> the lack of operational experience and the last paragraph of the section.

I would have said MUST.  We are trying to define a higher level of functionality than "lack of operational experience" would imply.   We have near zero operational experience with most of what we are talking about in homenet, because a lot of it hasn't been built, or only exists as lab implementations that still have operational issues to resolve.   So what should be in the document is what we want to achieve, not what we are sure we already know how to achieve.

Furthermore, speaking from my own operational experience with ULAs in the homenet, they do actually seem to work.   Source address selection does the right thing on the devices I use, although there may be issues on primitive legacy devices that I haven't tested.   So this really isn't an unreasonable thing to have in the document, particularly at the current rather modest level of requirement.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Jun 2013 06:25:55 -0700

> Could you please enumerate which specific concerns with the document that you raised during the last WGLC have not been addressed.

In particular:

http://www.ietf.org/mail-archive/web/homenet/current/msg02426.html

as far as I can tell is the end of involvement from the editors on the initial thread
and after listening to Orlando -- as I said, I wouldn't be there -- nothing was discussed
there about my last call comments that I can recall.

there was much discussion after that, but not much conclusive from the editors, afaict.
i did, on the other hand, learn that mdns saved a major corporation from obscurity. maybe
that's what's up.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Jun 2013 06:33:09 -0700

> I would have said MUST.  We are trying to define a higher level of functionality than "lack of operational experience" would imply.   We have near zero operational experience with most of what we a…

Er, that seems completely backward to me. Like you're forcing an expirement onto the unwashed masses that we really
don't know how it will turn out.

> Furthermore, speaking from my own operational experience with ULAs in the homenet, they do actually seem to work.   Source address selection does the right thing on the devices I use, although ther…

In particular, source address selection is still an ongoing concern. We may finally have some paper solutions that
claim to address all of the issues, but I think it's far from conclusive in the field how this will all turn out.

Homenet arch should be conservative, IMO. Once things get deployed to the masses, bad and/or poorly considered
solutions can come back to haunt us big time. ::cough:: NAT ::cough::

Mike

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jun 2013 10:11:34 -0400

> don't know how it will turn out.

Sure.   That's RFC 6204.   Maybe HIPnet, if that gets cleaned up a bit and gets traction.   Homenet is about building something newer and better than we have now, so yes, it is an experiment, and no, we are not forcing it onto the public before it is ready (and may I say that I really hate the term you just used for "the public"?).

> claim to address all of the issues, but I think it's far from conclusive in the field how this will all turn out.

While source address selection is still an ongoing concern, it works _quite_ reliably for ULAs, because SAS is a really easy problem to solve for that particular use case.

> solutions can come back to haunt us big time. ::cough:: NAT ::cough::

While what you say in the second sentence is certainly true, I don't see how it applies to the first.   If we only ever standardized things that were tried and true, we would still be sending email over the PSTN with modems using uucp.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Jun 2013 07:43:57 -0700

> Sure.   That's RFC 6204.   Maybe HIPnet, if that gets cleaned up a bit and gets traction.   Homenet is about building something newer and better than we have now, so yes, it is an experiment, and n…

A proposed standard carries a lot of weight, and I imagine that router vendors will give it due deference.
So it better be a lot more than an educated guess IMO. I'd really like to see that it gets hashed out in
enterprise space, for example, where there's a lot more expectation of clue to sort things out if theory
doesn't exactly map to reality.

> While source address selection is still an ongoing concern, it works _quite_ reliably for ULAs, because SAS is a really easy problem to solve for that particular use case.

SAS is bound up in all kinds of things including ULA's. I'm not saying that ULA's are bad or anything, but really that
especially in the face of mobility across administrative domains it's as far as I know rather murky. MAY is a hedge,
MUST is "we're really really certain". I for one don't feel that we've made it to that degree of certainty.

> While what you say in the second sentence is certainly true, I don't see how it applies to the first.   If we only ever standardized things that were tried and true, we would still be sending email…

There's an intermediate ground between theory and mass deployment without any expectation of clue: managed environments.
I'd say that we ought to be cautious before we proclaim victory and drink the beer on the homenet front. It's not like
enterprise, .edu, etc are not going to have to deal with these problems too, so let them take the arrows first.

Of course, if you want to make homenet arch experimental, MUST's for the experiment would be appropriate.

Mike

---

From: Dave Taht <[email-masked]>
Date: Mon, 17 Jun 2013 08:16:26 -0700

> incorrect, and that it should, er, SHOULD be fixed before publication.

+1.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Dave Taht <[email-masked]>
Date: Mon, 17 Jun 2013 08:21:51 -0700

On Mon, Jun 17, 2013 at 6:25 AM, Michael Thomas <[email-masked]> wrote:
>> Looking back at my list archive I see substantial discussion, including
>> notes from the document editor of changes made in response to your feedback
>> .  You were clearly *not* ignored.
>>
>> Could you please enumerate which specific concerns with the document that
>> you raised during the last WGLC have not been addressed.
>>
>> kind regards,
>
>
> In particular:
>

+10.

I had generally reverted to ignoring homenet's work until working code
showed up. Pointers to such on the OSPF front were discussed a month
or two back, but links to it are not on the wg page, but I was totally
unaware of the state of the code until then, and too busy since, to
look. Some work has been going on in openwrt around implementing
various homenet ideas but the work is far from baked enough to support
the RFC.

mdns ended up forking into mdnsext where some progress could actually be made.

-- 
Dave Täht

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jun 2013 12:05:01 -0400

> doesn't exactly map to reality.

Apparently you have never developed any new technology, and you expect that router vendors never will either.

> MUST is "we're really really certain". I for one don't feel that we've made it to that degree of certainty.

Right, and my original argument was that the current requirement was weaker than I would prefer, just as it is stronger than you would prefer.   It's almost as if it's a compromise between our two extreme positions.

> enterprise, .edu, etc are not going to have to deal with these problems too, so let them take the arrows first.

Again, you appear to be in the wrong working group.   The homenet working group was chartered to develop something new.   The way that happens is incrementally, and the incremental part of the process does involve experimentation, but the goal is to get to something solid, and it is valid for an IETF working group to attempt to get to something solid that doesn't yet exist and hence isn't _yet_ solid.

If _your_ goal is to do something really conservative, that's fine, but we already did that.   If your point is that you want to support HIPnet as an intermediate step, I think that's fine too.   But saying "we shouldn't do this, because we haven't done it yet" is pretty circular.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Jun 2013 09:45:12 -0700

First off, i have to say that 3.7 is much improved. it's been really hard to correlate my feedback from the
lack of response to my initial last call comments from the editors.

1) 3.7.1

    I still think that the intro could use more motivation from the problem space before jumping in
    and proclaiming that users will choose from some gui. It's sort of the heart of why any of this is
    important. It might be nice here or in section 3.7 to have some ascii art too showing the various
    elements (cer repository, isp/cloud dns names, announcers/mdns'ers, local names, global names, tunnels)
    to have something to point at.

2) "In practice
    however the underlying service discovery protocols should be capable
    of handling moving to a network where a new device is using the same
    name as a device used previously in another homenet."

I don't understand why they should be capable? What is the reason?

3) 3.7.8.  Devices roaming from the homenet

This is a new section and perhaps it's my fault, but isn't it a restatement that globally
accessible names need to be part of the global dns? Or is this the "vpn"-like situation where
I can see my local name space by virtue of having tunnelled back in? If the latter, it might
be worthwhile to contrast it with global naming so as to make it more clear.

4) 3.7.3

Much better, but I'm still sort of uncomfortable about whether we really want the ulqdn name.
It's been proposed, but it's not been very fleshed out, and I for one am not certain whether it
means that I a) might have to type one in or b) have to look at the uldqn suffix to differentiate.
It's not clear whether this document is the appropriate place to decide that, as I mentioned.

5) 3.7.4

Much improved. I like it a lot. Might it be better to move 3.7.8 if it's the latter interpretation
into this section? This section is talking about local naming, and it seems that talking about
tunnelling to see that naming might be appropriate here? (which was my mobility feedback).

6) 3.7.6

I still think it would be better to write this in terms of battery rather than specific networking
technology. It speaks to the actual problem rather than one specific case.

7) 3.7.7

I still don't understand what this section is trying to highlight. Is there a piece of code here
that needs to be written or not? I'm sorry if I'm being dense.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Jun 2013 10:02:27 -0700

> Apparently you have never developed any new technology, and you expect that router vendors never will either.

Huh? I've been around this plenty. Dev managers give a lot of weight to rfc's and feed the MUST's
and SHOULD's into their PERT charts (and completely ignore the MAY's). It's actually pretty shocking how
much deference they are given.

> Right, and my original argument was that the current requirement was weaker than I would prefer, just as it is stronger than you would prefer.   It's almost as if it's a compromise between our two…

MUST isn't strong, it's MUST. As in, no exceptions. SHOULD isn't a split the difference either. That really
only leaves MAY for us to split the difference, even if that's not exactly optimal.

> If _your_ goal is to do something really conservative, that's fine, but we already did that.   If your point is that you want to support HIPnet as an intermediate step, I think that's fine too.   B…

I don't think it's circular to say that we should be cautious about recommending things in the home environment which
are extremely difficult to change our minds about later. That's especially true when the recommendations don't have much
if any track record in the larger internet and are still a vexing problem. I'd say that SAS is absolutely in that category.
We have excruciating burn marks from getting addressing wrong before with NAT's. I'd rather we not incinerate ourselves a second
time.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Jun 2013 10:11:43 -0700

Michael Thomas wrote:

PS: I'd contrast SAS with the routing problems that are being solved here. I personally don't find
the problem all that compelling, but I do think we have a pretty damn good grip on what it means
because of our vast experience with it in isp and enterprise, etc. So I'm perfectly fine with us
pursuing it because of the low downside of harm.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jun 2013 13:45:40 -0400

On Jun 17, 2013, at 1:02 PM, Michael Thomas <[email-masked]> wrote:
> are extremely difficult to change our minds about later.

What we are doing in this working group is _not_ "recommending" things in the home environment.   We are trying to solve a problem that exists in the home environment for which no tried and true solution currently exists.

This is what I mean when I say you are in the wrong working group.   You are talking about this as if we were doing 6204bis, but that's a v6ops document, not a homenet document.

The HIPnet folks presented an interesting interim step along the way to homenet that doesn't depend on quite as much unknown technology, probably won't work as well ultimately, but may be a worthwhile step along the way.   I don't know if that's going to wind up being worked on in homenet or not; if it is, you might want to look at it, because it sounds like it's closer to what you have in mind.  But it doesn't address the full homenet architecture.   And that's because the homenet architecture document really is trying to do something new, _by design_.   If it didn't have the qualities that you ascribe to it as negatives, it would not be addressing the work that homenet was chartered to do, and hence couldn't be published in homenet.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Jun 2013 11:35:55 -0700

> What we are doing in this working group is _not_ "recommending" things in the home environment.   We are trying to solve a problem that exists in the home environment for which no tried and true so…

Requiring MUST on ULA's to solve for disconnected reachability better mean that we understand the
operational complexity of ULA's. ULA's are not the v6 equivalent of net 10 addresses, after all. The
v6 model of acquiring as many addresses as routers advertise really exacerbate the SAS problem and our
inadequacy of solving SAS in the last 10 years make this all a big science experiment, IMO. In isolation,
sure, ULA's work well. But how do they interact with VPN and other tunnelling technologies, and their ULA's?
How are boundaries established? What are boundaries, for that matter (one, of the charter items as I recall)?
I'd really be worried that the architecture document specifies a MUST unless we're really, really sure. Maybe you
are, but in the countless times I have brought this up here and elsewhere I feel that those kinds of
problems just get paved over in the rush to get things out.

Mike

---

From: "Weil, Jason" <[email-masked]>
Date: Mon, 17 Jun 2013 15:12:45 -0400

Ted,

This brings up a question that I have been struggling with for some time.
The goal of this WG based on your description is to solve the home
networking problems that exist with the addition of IPv6 and multiple
subnets and all that entails as it relates to the removal of NAT, service
discovery, naming and security impacts, etc.

What is still not completely clear in my mind is whether we are creating
the destination endgame design unhindered by current design/s or if we are
creating the endgame design that can be incrementally reached without a
greenfield deployment? If the end-game includes support for incremental
migration which I for one believe it should, then it seems like some
verbiage for this requirement needs to be included in the architecture. I
am open for working this wording in if there is consensus. If there is
consensus that this is not in scope and there is no bridge required from
v6ops or other current operational groups to homenet then that will
require a different group of people and maybe a different WG (maybe v6ops
or something else?) to figure out how to get from where we are now to
where we want to go.

The HIPnet work feels like a good attempt at how to bridge the gap. It may
not be the only solution, but is the only one I have seen proposed so far.
My general feeling though is most people on the list aren't concerned with
how to bridge the gap other than service providers and equipment vendors
selling to those service providers who are actively working on pieces of
this solution today. My concern is if there is no plan for an incremental
solution to get to the Homenet architectural goal then there very well may
be a divergence of design paths that may complicate any possibility of
future convergence.

Thanks,

Jason

On 6/17/13 1:45 PM, "Ted Lemon" <[email-masked]> wrote:

>> I don't think it's circular to say that we should be cautious about
>>recommending things in the home environment which
>What we are doing in this working group is _not_ "recommending" things in
>the home environment.   We are trying to solve a problem that exists in
>the home environment for which no tried and true solution currently
>exists.
>
>This is what I mean when I say you are in the wrong working group.   You
>are talking about this as if we were doing 6204bis, but that's a v6ops
>document, not a homenet document.
>
>The HIPnet folks presented an interesting interim step along the way to
>homenet that doesn't depend on quite as much unknown technology, probably
>won't work as well ultimately, but may be a worthwhile step along the
>way.   I don't know if that's going to wind up being worked on in homenet
>or not; if it is, you might want to look at it, because it sounds like
>it's closer to what you have in mind.  But it doesn't address the full
>homenet architecture.   And that's because the homenet architecture
>document really is trying to do something new, _by design_.   If it
>didn't have the qualities that you ascribe to it as negatives, it would
>not be addressing the work that homenet was chartered to do, and hence
>couldn't be published in homenet.
>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 17 Jun 2013 16:13:53 -0400

In my opinion, the subnetting architecture for home networks needs to be more carefully addressed in this document.

As I read the document, the logical network topology is not clearly differentiated from the physical topology.  Several of the motivations for a subnet architecture, including traffic isolation for security and traffic management for QoS, are really dependent on the logical topology, and a physical topology of randomly connected devices is not likely to provide the desired logical topology.

The document makes no mention of *how* a largest practical subnet architecture might be achieved.  There should be some requirement that devices be capable of acting as either a bridge or a router (or a mix of both), and that devices should bridge unless routing is determined necessary.

Acknowledging the desire to avoid constraining future networks, I think the document would benefit from some discussion of scaling goals: how many subnets, how many ISP connections, etc.  also, some text about how much and what user configuration is acceptable should be added.  As a specific example, network devices can't know, without user input, whether s guest network us desired and how devices should be guided to attach to the guest network.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jun 2013 16:36:40 -0400

> discovery, naming and security impacts, etc.

Sure.

Whether HIPnet will get worked on, and by which working group, is, I think, an open question.   Personally I see it as a good incremental step between 6204bis and the full homenet solution, and I'd like to see it worked on because it's pretty clear to me that there's demand for it now.   I would be very disappointed if HIPnet were the final output of this working group, and I don't think here's much enthusiasm for that path anyway.   But while there might be enthusiasm for skipping HIPnet, I think we will leave the demand for a near-term solution unmet if we do that, and that might turn out to be expensive.

My suspicion is that it will be possible once homenet, hipnet (assuming it gets worked on) and 6204bis are done to have a provider infrastructure that supports all three, so that no greenfield upgrade will be required.   But there's no way to deploy that architecture now, because we don't know everything we need to know to deploy it.   So I think realistically an ISP that deploys a 6204bis or HIPnet infrastructure in the near term will almost certainly have to re-tune their deployment to support homenet in the future.   I think there are a lot of things that can be done to minimize the pain that's caused by that upgrade, but I don't think anybody should plan on the homenet router being a drop-in replacement with full functionality and no changes on the provider network.

In particular, the DNS solution isn't fully fleshed out yet.  You can deploy 6204bis with a /64, but that's not going to work for homenet or hipnet.   I _think_ those are the two sticking points, but it wouldn't shock me deeply if more surface as we go forward.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 17 Jun 2013 17:09:30 -0400

On Jun 15, 2013, at 2:35 PM 6/15/13, Curtis Villamizar <[email-masked]> wrote:

> [...]

I think Curtis has made a good suggestion that deserves some discussion.  I, too, have some concerns (expressed in a recent post to the WG mailing list) about the document, yet I think it is very good and far enough along to be used as the basis for discussion of other documents and possible adoption of some additional WG documents.

So, I suggest it's appropriate for the WG to use the current version of homenet-arch as the basis for discussion of other documents, while, in parallel, completing and publishing a revised version of homenet-arch as a document of record, while maintaining, as Curtis suggests, a living document (perhaps as a homenet-arch-bis I-D?) that records changes in thinking about the hoemnet architecture as the protocol suite is developed.

And, I realize how many WG architecture documents have been OBE and never published in a final version.  I think the homenet WG has adopted a wise strategy encouraging work on the architecture document to avoid the "ready, fire, aim" syndrome.

- Ralph

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Jun 2013 10:10:36 +0200

Jason,

> be a divergence of design paths that may complicate any possibility of

that's an interesting question. it isn't clear to me if hipnet is incrementally
taking us closer to the end goal, or if it makes the transition
from a single CPE to a routed network much harder.

if my assumption of the latter is correct, what can we do to minimize the damage?
could hipnet be scaled back to the simpler case of two routers being piggy-backed?

cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Jun 2013 09:04:54 -0400

Ole Troan <[email-masked]> wrote:
    >> The HIPnet work feels like a good attempt at how to bridge the gap. It
    >> may not be the only solution, but is the only one I have seen proposed
    >> so far.  My general feeling though is most people on the list aren't
    >> concerned with how to bridge the gap other than service providers and
    >> equipment vendors selling to those service providers who are actively
    >> working on pieces of this solution today. My concern is if there is no
    >> plan for an incremental solution to get to the Homenet architectural
    >> goal then there very well may be a divergence of design paths that may
    >> complicate any possibility of future convergence.

    ot> that's an interesting question. it isn't clear to me if hipnet is
    ot> incrementally taking us closer to the end goal, or if it makes the
    ot> transition from a single CPE to a routed network much harder.

My review of the CableLabs Homenetworking stuff (I won't call it
HIPnet, due to RFC4423 and friends) is that it is a dead end.

If we fix it enough to accomodate an upgrade that supports topologies with
loops, then we already have accomplished homenet.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Weil, Jason" <[email-masked]>
Date: Tue, 18 Jun 2013 09:45:28 -0400

I was using HIPnet as an example as it is the only one that I am aware.
The question though was should the architecture have wording to support a
path to the proposed destination from where we are today or are we just
assuming that backward compatibility is not achievable? Ted has a good
point though in that we need to see what the architecture is going to be
before we are able to understand if we can migrate to it.

Jason

On 6/18/13 4:10 AM, "Ole Troan" <[email-masked]> wrote:

>>may

---

From: Ray Bellis <[email-masked]>
Date: Tue, 18 Jun 2013 13:58:53 +0000

combining a couple of messages:

On 17 Jun 2013, at 21:36, Ted Lemon <[email-masked]> wrote:

> My suspicion is that it will be possible once homenet, hipnet (assuming it gets worked on) and 6204bis are done to have a provider infrastructure that supports all three, so that no greenfield upgrade will be required.

My expectation is that neither HIPnet nor Homenet require any specific changes at the provider network.

Particularly w.r.t. the network topology and prefix delegation, all of the changes are from the LAN side of the CPE.

> from a single CPE to a routed network much harder.

<chair hat="on">

My reading of HIPnet is that it would *not* permit a natural progression to the full Homenet solution as currently envisaged by the WG.

The corollary of that, as Øle aludes to is that deployment of HIPnet may indeed make it *harder* to transition to a fully routed network in the future.

We would welcome feedback from the HIPnet authors on how they would anticipate supporting co-existence and/or transition from HIPnet to "full" Homenet.
 
</chair>

kind regards,

Ray

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jun 2013 10:18:48 -0400

> My reading of HIPnet is that it would *not* permit a natural progression to the full Homenet solution as currently envisaged by the WG.

I think by this you mean that a home network that has HIPnet routers probably won't work if you try to add Homenet routers to it, right?

---

From: Ray Bellis <[email-masked]>
Date: Tue, 18 Jun 2013 14:26:09 +0000

> I think by this you mean that a home network that has HIPnet routers probably won't work if you try to add Homenet routers to it, right?

Something like that, yes.

It might work if the Homenet routers were attached as stubs "below" HIPnet routers, but I don't think you could fully mesh and/or mix them.

Ray

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jun 2013 10:29:19 -0400

> It might work if the Homenet routers were attached as stubs "below" HIPnet routers, but I don't think you could fully mesh and/or mix them.

Right.   I think this limitation applies to 6204bis routers as well, though, doesn't it?

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 18 Jun 2013 10:47:05 -0400

What technical constraints are present that do not allow us to move to a
homenet future (currently envisioned one in the WG) world?

If they are present, are those constraints any different then the ones we
have moving from what we have today (6204/6204bis) to the envisioned future
homenet?

I don't think greenfield is a practical way to look at
how future home networks will come to be, therefore some evolution is
likely needed.

regards,

Victor K

On Tue, Jun 18, 2013 at 10:18 AM, Ted Lemon <[email-masked]> wrote:

> > My reading of HIPnet is that it would *not* permit a natural progression
> to the full Homenet solution as currently envisaged by the WG.
>
> I think by this you mean that a home network that has HIPnet routers
> probably won't work if you try to add Homenet routers to it, right?
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Jun 2013 11:16:07 -0400

Ted Lemon <[email-masked]> wrote:
    tl> On Jun 18, 2013, at 10:26 AM, Ray Bellis <[email-masked]>
    tl> wrote:

    >> It might work if the Homenet routers were attached as stubs "below"
    >> HIPnet routers, but I don't think you could fully mesh and/or mix
    >> them.

    tl> Right.  I think this limitation applies to 6204bis routers as well,
    tl> though, doesn't it?

6204, for sure.
is there a diff for 6204bis?

1) A 6204 would work downstream of CableLabsHome ("HIPnet") machine.

2) A homenet router, attached to the same LAN("0") as 6204, and a different
   ISP upstream, would cooperate, but there would be egress issues
   for hosts on that LAN0 if they picked the wrong default router.
   LANn on additional homenet router below LAN0 would be fine.

3) A homenet router, below a CableLabsHome would think that that interface
   was an upstream (external) interface.

4) A CableLabsHome, below a homenet router would see no Internet, so
   it would be turned off.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jun 2013 11:24:57 -0400

> 4) A CableLabsHome, below a homenet router would see no Internet, so

This would be easy to fix.   It would be hard to make it work well, but it would be easy to make it work at least as well as 6204bis.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Jun 2013 15:07:44 -0400

>> 4) A CableLabsHome, below a homenet router would see no Internet, so

    tl> This would be easy to fix.  It would be hard to make it work well,
    tl> but it would be easy to make it work at least as well as 6204bis.

I am incorrect on two counts.  

1) IPv6. It woud do a RA, and it would get an answer, but said answer
would lead to a DHCPv6 server that gives it no prefixes, if homenet
distributes prefixes via zOSPF (or another routing protocol). 

To fix it, one would have to add chained DHCPv6-PD to homenet.  
Having done this, there would be no loop detection, and poor multiple-ISP
support.  I don't see the value in the half-step.

2) IPv4+NATwork would work "fine". (I mean, it would fail for all the reasons
that it fails today, including cables plugged in wrong, and printers being
on the wrong side of the "switch", etc..)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 18 Jun 2013 21:53:55 +0200

> incorrect, and that it should, er, SHOULD be fixed before publication.

It looks like this discussion has stalled.

Dear editor -- have we agreed that the second paragraph of Section 3.5
is going to be removed?

-- Juliusz

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Jun 2013 22:54:14 +0200

Juliusz,

> Dear editor -- have we agreed that the second paragraph of Section 3.5

I agree with your statement on "consistent view of the network".
I would like to keep the second paragraph, what if we did s/consistent/complete/?
and removed "which implies a link state is preferable."?

second paragraph section 3.5 routing functionality:

   "The homenet unicast routing protocol should preferably be an existing
   deployed protocol that has been shown to be reliable and robust, and
   it is preferable that the protocol is both 'lightweight' and that
   open source implementations are readily available.  It is desirable
   that the routing protocol has knowledge of the homenet topology.
   This would mean the routing protocol gives a complete view of the network,
    and that it can pass around more than just routing information."

the one example I was thinking of that requires a complete topology view
was the case where there is a single DHCP server assigning prefixes to 
the links in the network. two routers on a link, both asking for a prefix, the
DHCP server knowing the topology could then assign a single prefix to the link.

cheers,
Ole

---

From: Dave Taht <[email-masked]>
Date: Tue, 18 Jun 2013 14:19:54 -0700

>    "The homenet unicast routing protocol should preferably be an existing

I assume that by unicast you mean that a separate multicast routing
protocol can co-exist, not that the routing protocol communicates via
unicast.

Perhaps it would be good to address the multicast routing protocol
issue somewhere?

>    deployed protocol that has been shown to be reliable and robust, and

Sure. My biggest bugaboo about mandating a protocol has always been is
that I'm not aware of any that meet that requirement in wireless
networks, which I expect to dominate in the home. I would certainly
love to see people working on it...

>    it is preferable

is mandatory. is rfc-ese dying out? MUST

> that the protocol is both 'lightweight' and that
>    open source implementations are readily available.

It is desirable that the size of the daemon and the data are also
lightweight so as to be suitable for use on small embedded devices.

I perversely enjoyed watching the early attempts at big daemons for
dhcpv6 go by...

> It is desirable

To me that's sort of a given. "the routing protocol MUST have knowledge"

>    This would mean the routing protocol gives a complete view of the network,

If you are still trying to back in linkstate into the requirement,
it's simpler to say so.

>     and that it can pass around more than just routing information."

embedding new TLVs and behaviors are possible with any protocol.

-- 
Dave Täht

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 18 Jun 2013 23:46:43 +0200

> I would like to keep the second paragraph, what if we did
> s/consistent/complete/?  and removed "which implies a link state is
> preferable."?

I have absolutely no problem with requiring a link-state protocol.
I realise that OSPF and RIP are the only widely deployed protocols
that are open, implemented by multiple vendors and shown to be robust;
given the bad press that RIP has received, I think we can take it as
a given that OSPF will be chosen for Homenet, whether some of us like
it or not.

What I do want to avoid is unwarranted, overly-general statements that
disparage distance-vector protocols.  So please feel free to promote
OSPF, there's just no need to slander the competition.

>     and that it can pass around more than just routing information."

Yeah, that's fine with me.  I'm not a native speaker, but here's my
best attempt:

    The homenet unicast routing protocol should be a previously deployed
    protocol that has been shown to be reliable, robust, to allow
    lightweight implementations, and of which open source
    implementations are available.  It is desirable, but not absolutely
    required, that the routing protocol be able to give a complete view
    of the network, and that it be able to pass around more than just
    routing information.

You already know my opinions about hijacking a routing protocol for
passing around non-routing information -- I believe that this is
better achieved by a separate flooding protocol, as I've tried to show
with AHCP[1] -- which is why I'd appreciate it if you kept the "not
absolutely required" formulation.

> the one example I was thinking of that requires a complete topology
> view was the case where there is a single DHCP server assigning
> prefixes to the links in the network. two routers on a link, both
> asking for a prefix, the DHCP server knowing the topology could then
> assign a single prefix to the link.

There are other reasons as well.  I urge you not to understate the
marketing value of a web interface that displays the network topology
to the user.  We've done quite a bit of work in distance vector
protocols to do that[2], but there's absolutely no doubt that that's
something that's easier to achieve with a link-state protocol.

-- Juliusz

[1] http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/
[2] http://babelweb.pps.univ-paris-diderot.fr

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 18 Jun 2013 23:50:39 +0200

> [2] http://babelweb.pps.univ-paris-diderot.fr

Sorry, that's

  http://babelweb.wifi.pps.univ-paris-diderot.fr

--jch

---

From: "Mark Baugher (mbaugher)" <[email-masked]>
Date: Tue, 18 Jun 2013 22:31:05 +0000

> Perhaps it would be good to address the multicast routing protocol

It's addressed in 3.5.1.  Is there a non-flooding, self-configuring routing protocol?  I expect if there were an appropriate one, the authors would name it.  Maybe flooding is not so bad for low-rate flows like service discovery.

Mark

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Jun 2013 23:57:11 +0100

Hi,

Just a note to say that as the main editor I had a 30 min chat with the WG co-chairs Ray and Mark today in which we discussed the WGLC feedback. The chairs will be posting an update soon. Below are some responses in the meantime. I hope these are in line with the WG chair views; if not, I'm sure Ray or Mark will correct/clarify.

Firstly, the -08 version was produced after reading some 500-600 emails over many threads, either side of the Orlando IETF meeting. It was impractical to respond to every point by email. No views were ignored, rather I attempted to draw consensus from the views posted, without being swayed by the volume of comments from some posters.  It seems that more recent comments agree that -08 is improved as a result.

The architecture text describes general principles and requirements, but not in 2119 language. As a document, it should thus be viewed as a guide as to where homenet is heading, based on the consensus of the WG. It is not intended to provide every specific detail in this text; further documents will do that, e.g. for homenet naming and service discovery, where I certainly agree that more detailed work is needed, some of which will hopefully be linked to the BoF on that topic in Berlin. Thus, for example, while forming the largest possible subnets has been agreed as desirable, the text does not prescribe how that should be achieved. Similarly the document does not intend to imply that mDNS is a given (it is cited as an example of a zeroconf solution), or, given it's come up in this thread, a link-state routing protocol.

Perhaps the most contentious issue is the use of ULAs; may, should or must? It seems there's consensus that the text should be at least a "should". There is a parallel ula-usage draft that Sheng Jiang is working on with others. This also brings up the point on whether we are designing with today's system constraints in mind, e.g. where older systems are less likely to do appropriate address selection when deployed in a homenet that only has external IPv4 connectivity, but has ULAs turned on internally. In general, I don't feel we should constrain the design, but we do state that there is a preference for established/proven protocols, and running (open source) code, and that changes to hosts and routers should be minimised. 

Regarding hipnet, it seems there needs to be a transition/coexistence path between what we have today, hipnet, and the final homenet-arch solution.  I believe hipnet is largely homenet-arch compliant, though there are some areas where it is not, e.g. efficient use of prefixes, and support for multihoming.

On personal drafts that have expired, or that there has been minimal list discussion on, the plan is to continue to remove the "dangling" references, but to ensure the spirit of the drafts is captured where appropriate to do so.

And some specific comments/proposals towards -09:
- the ULQDN concept will be retained
- a sentence will be added regarding supporting mobile devices within the home
- the firewall text appears appropriate, though some could be pruned without changing the tone/balance
- the routing text can make it clear that link-state is not the only solution, or not refer to link-state at all. We have some text from Ole. The word "consistent" should be "complete", a typo
- a sentence will be added to clarify that multicast can be sourced to/from the home, not just within it.
- no text will be added about extension headers (too fine a detail)

Tim

---

From: Teco Boot <[email-masked]>
Date: Wed, 19 Jun 2013 07:43:59 +0200

My opinion:
It is a nice feature of a routing protocol if such can provide a transport for other purposes. But let's think twice (or more) before using. It creates unnecessary dependencies. While homenet would come up with a single zero-config routing protocol, autoconfig is needed everywhere. I see two options: come up with signaling that can be transported over foo or come up with own transport. Something in the middle: transport over something that is always there (e.g. NDP RA). RA has the advantage that hosts can easily benefit (SAS).

Teco

---

From: Steven Barth <[email-masked]>
Date: Wed, 19 Jun 2013 10:21:38 +0200

> I perversely enjoyed watching the early attempts at big daemons for

I'd like to +1 this one.

I don't really like hipnet as a whole because I think its overengineered 
at various points, however the general idea of using chained DHCPv6-PD 
kind of makes it self contained and I think it would be much easier to 
get deployed in the wild despite some of the architectural problems that 
have to be solved adequately first (say border and loop-detection).

What I mean is, I don't see any bigger routing daemons and stacks 
getting integrated into the majority of home routers because simply of a 
lack of incentives. A DHCPv6-server is most likely there anyway so I 
guess adding the little bit of PD-support + maintaing it could be 
justified. However a whole separate OSPF or so daemon + routing stack 
with 100s of KB and all the inherent logic just for a few very advanced 
usecases? I doubt it. I mean we are still talking about home networks 
and home routers aren't we?

Cheers,

Steven

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 19 Jun 2013 09:58:09 +0200 (CEST)

On Wed, 19 Jun 2013, Steven Barth wrote:

> I mean we are still talking about home networks and home routers aren't 
> we?

I already know people with a lot of temperature sensors, power sensors etc 
in their residential dwellings. When I talk to non-technical people about 
the possibility of using an App in their phone to turn on the heater/AC in 
their summer home when they're on the way, they get really interested.

There are a lot of use-cases where it would be beneficial to have things 
work well regardless of topology for devices being connected. I know 
people today who have connected up multiple NAT44-routers deep just 
because they don't know better, and this is of course not beneficial to 
the user experience.

What is your vision of the typical home data solution in 10-20 years? I 
see 60Ghz wifi basestations needing to be in each room, a multitude of 
sensors that need separate routing domains because they're not ethernet, 
and my guess is that people don't want to do separate wiring for all these 
devices. I would like these things to "just work" when you hook them up.

---

From: Steven Barth <[email-masked]>
Date: Wed, 19 Jun 2013 11:23:42 +0200

On 19.06.2013 09:58, Mikael Abrahamsson wrote:
> I already know people with a lot of temperature sensors, power sensors
> etc in their residential dwellings. When I talk to non-technical people
> about the possibility of using an App in their phone to turn on the
> heater/AC in their summer home when they're on the way, they get really
> interested.
Nothing wrong with that and nothing preventing them from working.

> and my guess is that people don't want to do separate wiring for all
> these devices. I would like these things to "just work" when you hook
> them up.
>

Right I agree. Especially that users do and will chain routers. Maybe 
even non-ethernet/WiFi at some point. This is a must for homenet but 
this is also what chained DHCPv6-PD / a hipnet-like solution can do.

But let me ask the other way: What relevant usecase would such a 
solution not cover? or What would be covered better by something like 
OSPF in a home network?

I'd just like to avoid a solution which adds much complexity and 
provides more features than actually needed today just because it could 
be useful in a later future where we don't even know if today's solution 
is even relevant for what we need because e.g. as you said sensors might 
need totally different routing.

-Steven

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Jun 2013 10:26:48 +0200

Steven,

> I don't really like hipnet as a whole because I think its overengineered at various points, however the general idea of using chained DHCPv6-PD kind of makes it self contained and I think it would be much easier to get deployed in the wild despite some of the architectural problems that have to be solved adequately first (say border and loop-detection).
> 
> What I mean is, I don't see any bigger routing daemons and stacks getting integrated into the majority of home routers because simply of a lack of incentives. A DHCPv6-server is most likely there anyway so I guess adding the little bit of PD-support + maintaing it could be justified. However a whole separate OSPF or so daemon + routing stack with 100s of KB and all the inherent logic just for a few very advanced usecases? I doubt it. I mean we are still talking about home networks and home routers aren't we?

as one of the co-authors of DHCPv6 PD, I must emphasise that PD was never designed for this and does not work very well.
DHCP does not work with multiple sources of information. meaning that if you are multi-homed and have separate routers
serving each connection, then you're in trouble.

as a data point for a non advanced use case, I just moved in to a new flat and discovered that the flat was already multi-homed with native IPv6. a 70/10M cable connection and a 100/30M VDSL connection. I need to make this work.

what's special about the home network? we have been running routing protocols in networks for decades. why should we only put lobotomised schemes in the home?

cheers,
Ole

---

From: Steven Barth <[email-masked]>
Date: Wed, 19 Jun 2013 11:42:39 +0200

> what's special about the home network? we have been running routing protocols in networks for decades. why should we only put lobotomised schemes in the home?
Well honestly from a technical perspective I wholeheartedly agree with you.
I'm just pessimistic about it getting anywhere deployed widely.

What's different or special about home networks?
There's millions or billions of them. They usually use cheap routers 
with limited resources. And I don't think that is going to change 
anywhere in the near future. So while technically a full-blown routing 
protocol or even using more enterprisey routing is probably superior 
there are IMO other factors that limit the practically of it.

I'm just saying that a DHCPv6-PD based solution - maybe with some of the 
most concerning issues fixed / circumvented - could have a much better 
chance of being adopted widely. I mean in the end defining standards 
that are never going to get used makes little sense as well.

I know it's just one perspective and it's not even technical but I think 
nevertheless it should at least be considered.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 19 Jun 2013 10:49:08 +0200 (CEST)

> solution not cover? or What would be covered better by something like 

Let's say you have a cable Internet operator, handed off in a coax outlet 
next to your TV in your living room. The coax goes to their CER, which 
hands off an ethernet port. At the other end of the apartment/house, your 
FTTH connection is handed off in a media converter, also a CER. You 
connect a wireless AP to each of these and also connect up them together, 
so you have identical behaving SSID across the different domains, you 
prefer the APs to be routers, because you also have non-ethernet sensors 
you want to hook up. Now a PD hierarchy from each CER will cross each 
others, and how do you know what packet to send where to avoid uRPF 
filtering for each set of addresses? Perhaps you also want to build a ring 
of the APs around your house so in case you need to change out one of 
them, you don't break connectivity to everything else.

I don't see how this can be solved without distributing more information 
to routers than they would have using purely DHCPv6-PD.

I'm sure some will say above is bordering on overengineering and it's more 
"enterprise", but I believe people will want the above to work because 
their homenet will be more crucial to them in 10-20 years than it is 
today. I know a lot more people using RAID5 or RAID6 today compared to 10 
years ago, same thing with backups etc.

> need totally different routing.

"Totally different routing"?

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Jun 2013 10:54:26 +0200

>> I'd just like to avoid a solution which adds much complexity and provides more features than actually needed today just because it could be useful in a later future where we don't even know if today's solution is even relevant for what we need because e.g. as you said sensors might need totally different routing.
> 

exactly. trying to create a working network with static routes created by snooping on DHCP packets and making assumptions of the directionality of the network by listening to RAs, creating a spanning tree at L3...

now if that isn't complex and brittle... a dynamic routing protocol seems quite simple in comparison.

cheers,
Ole

---

From: Mark Townsley <[email-masked]>
Date: Wed, 19 Jun 2013 11:59:48 +0200

> I'm just pessimistic about it getting anywhere deployed widely.

I understand your pessimism. That said, based on what we saw presented at the last IETF, even the IEEE seems to be headed towards using IS-IS in the home. Imagine the Irony of not having a routing protocol at L3 in the IETF, while having one defined in the IEEE for use at L2. The 6lowpan sensor world has figured out how to run routing protocols on tiny, tiny, devices. CeroWRT has been running routing protocols for years. When I look around, the routing protocol pessimism seems to be a rather localized one. 

Ultimately, I think we should be guided by what is technically correct, balanced with what we can find interoperable, preferably open source, implementations of.

- Mark

> There's millions or billions of them. They usually use cheap routers with limited resources. And I don't think that is going to change anywhere in the near future. So while technically a full-blown routing protocol or even using more enterprisey routing is probably superior there are IMO other factors that limit the practically of it.
> 
> I'm just saying that a DHCPv6-PD based solution - maybe with some of the most concerning issues fixed / circumvented - could have a much better chance of being adopted widely. I mean in the end defining standards that are never going to get used makes little sense as well.
> 
> I know it's just one perspective and it's not even technical but I think nevertheless it should at least be considered.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 19 Jun 2013 10:08:53 +0000

On 18 Jun 2013, at 22:46, Juliusz Chroboczek <[email-masked]> wrote:

> I think we can take it asa given that OSPF will be chosen for Homenet, whether some of us like it or not.

Actually I don't think that's a given at all.

It happens that the initial efforts by some participants have focused on OSPF, but I hear there's quite a few people now thinking that IS-IS would be a better choice.

Lack of open source implementations is a potential impediment, of course, although it's expected that BIRD (from cz.nic) will have IS-IS support some time pretty soon.

Ray

---

From: Tim Chown <[email-masked]>
Date: Wed, 19 Jun 2013 11:37:11 +0100

> Lack of open source implementations is a potential impediment, of course, although it's expected that BIRD (from cz.nic) will have IS-IS support some time pretty soon.

So we've seen some examples of the zeroconf prefix assignment/configuration in action through implementations of draft-arkko-homenet-prefix-assignment-04 and draft-ietf-ospf-ospfv3-autoconfig-02. These have used Bird and Quagga. While obviously just proof of concept, these were deployed on commodity devices. The Bird implementation went further, supporting src&dst based routing, which was demonstrated at the previous two IETFs.

It would be interesting to see the equivalent solution based on IS-IS. I'm not sure who the "quite a few people" are, but it would be a good time for them to put something more tangible forward.

Prior discussions have also proposed other routing protocols for homenet.

As someone else mentioned, the prefix and routing information could be passed in ND/RAs, or that function could potentially be part of any extended naming/SD protocols that emerge from the "mdnsext" BoF and subsequent work. What the homenet-arch text needs to capture is the general principles/requirements.  I think with the changes suggested by Ole, which are fairly minor, it will do so.

Tim

---

From: Teco Boot <[email-masked]>
Date: Wed, 19 Jun 2013 12:47:14 +0200

Quite some time ago (25nov2011) I suggested to consider IS-IS and TRILL.

It happens to be I manage my own small home network. I have 2 WiFi APs with same SSIDs. I have to use single access subnet, WiFi stacks make such assumption. How can I subnet my homenet without breaking my WiFi service? 

Teco

---

From: Steven Barth <[email-masked]>
Date: Wed, 19 Jun 2013 12:47:51 +0200

Mark Townsley <[email-masked]> wrote:
>I understand your pessimism. That said, based on what we saw presented
>at the last IETF, even the IEEE seems to be headed towards using IS-IS
>in the home. Imagine the Irony of not having a routing protocol at L3
>in the IETF, while having one defined in the IEEE for use at L2. The
>6lowpan sensor world has figured out how to run routing protocols on
>tiny, tiny, devices. CeroWRT has been running routing protocols for
>years. When I look around, the routing protocol pessimism seems to be a
>rather localized one. 
>
>Ultimately, I think we should be guided by what is technically correct,
>balanced with what we can find interoperable, preferably open source,
>implementations of.

Well I guess the compromise would be something lightweight then. I find ospf - as proposed - too heavy-duty for that. Maybe something based on IS-IS if you already mentioned it?

Maybe having a small lightweight open source daemon -preferrably outside of bird / quagga? - that can be easily integrated into the native firmware source policy based routing without carrying too much unnecessary bloat.

-Steven

---

From: Acee Lindem <[email-masked]>
Date: Wed, 19 Jun 2013 12:48:13 +0000

> Well I guess the compromise would be something lightweight then. I find ospf - as proposed - too heavy-duty for that. Maybe something based on IS-IS if you already mentioned it?

It has been my experience that ISIS and OSPF without accoutrements are similar in code size and complexity. Both these protocols have experienced decades of extensions to meet the requirements of service provider and, to some extent, large enterprise networks. Many of these extensions are not needed in home nets. 

If you add layer 3 transparency on top of the routing protocol, e.g., TRILL or SPB, that is another layer of complexity. However, if the technology is mature and better meets the requirements, I'm not sure that complexity or code size should be the primary concern. 

Acee

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Jun 2013 08:56:43 -0400

Steven Barth <[email-masked]> wrote:
    sb> Right I agree. Especially that users do and will chain routers. Maybe
    sb> even non-ethernet/WiFi at some point. This is a must for homenet but
    sb> this is also what chained DHCPv6-PD / a hipnet-like solution can do.

it can deal with tree-like topologies with a single ISP.

It can not deal with loops: I see them regularly in people's small offices,
and given wifi, it's really easy even for experts to create.

    sb> I'd just like to avoid a solution which adds much complexity and
    sb> provides more features than actually needed today just because it
    sb> could be useful in a later future where we don't even know if today's
    sb> solution is even relevant for what we need because e.g. as you said
    sb> sensors might need totally different routing.

The solution that has been demoed appears pretty light weight.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jun 2013 13:39:51 -0400

> The document makes no mention of *how* a largest practical subnet architecture might be achieved.  There should be some requirement that devices be capable of acting as either a bridge or a router…

I find this text in the document a bit problematic too.   I don't think it's actually reasonably practical to do any such determination.  The only practical source of subnet sizing is the size of the smallest prefix we got from an ISP.   I guess there are some ideas we could suggest, but they look more like solutions than architecture to me.

For instance, we could say that for any given router, all non-edge interfaces on that router that are of the same media type should be bridged together into a single subnet.   CeroWRT makes each one its own subnet, which drives me nuts.   This would have the effect that if you plugged a Wifi router's ethernet port into the ethernet port of a CER, the WiFi router's ethernet port would be on the same subnet as the CER's ethernet ports, but the Wifi network would be on its own subnet; hence, routed, not bridged, which I think is desirable.   But does this belong in the architecture document?

Furthermore, it's complicated by the fact that we'd really prefer to avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite possible that people will plug such interfaces together.   So we may need to decide very dynamically which interfaces are bridged and which are routed.   Maybe we will have virtual bridged networks on each homenet router for each media type and speed that the router supports, and dynamically connect interfaces that are running at that speed to those bridges, and hope that this works.

I don't think we've visited this issue thoroughly enough to make statements about it in the architecture document.

> Acknowledging the desire to avoid constraining future networks, I think the document would benefit from some discussion of scaling goals: how many subnets, how many ISP connections, etc.  also, som…

I think that these are all reasonable things to want to describe; the question is, does the working group want to describe them, particularly in the current rev of the architecture document.   My impression is that at the moment the working group is willing to leave these things out of the architecture document.

The document at the moment assumes the ability to support multihoming for N connections, where N can definitely be 2, and possibly an arbitrarily large number greater than two, but probably not.   I think it would indeed be worth making this explicit in the architecture document.   If we don't, I think some people will tend to read the architecture document as really only requiring support for a maximum of two CERs and two ISP connections.

How many subnets is determined by the size of the prefix we are given.   If we get a /64, the whole homenet is going to have to be a single subnet, like it or not.   If we get a /48, we can have a subnet for every device, which would be pretty silly.

This leads to a separate question that is also interesting: what if we are multihomed, and one ISP gives us lots of prefix, and the other ISP gives us a /64?   Do we bridge, to accommodate the chintzy ISP?   Do we route, and just ignore the second ISP?   Do we just subnet the /64 down, and run those micro-prefixes as managed prefixes using DHCPv6?

I think none of these options works well, if at all, and this scenario is a very realistic possibility, e.g. in the case of a dual-homed home that's connected to a wireline ISP that provides a /56, and a wireless ISP that provides a /64.   If Comcast ever gets me a native IPv6 connection, that will in fact be my home network environment.   The current architecture document does not discuss this scenario, although it grazes frustratingly close to doing so in section 3.4.3.

3.3.3 does talk about guest realms, which I think is adequate.   Talking about UI is probably unnecessary, since it's implicit that some UI is needed, and since the text in 3.3.3 isn't nearly sufficient to implement guest realms; a document describing how this works on a homenet will be necessary, and if the working group (which includes you!) decides to talk about UI in that document, then we'll cover it there; otherwise not.

The beginning of 3.3 talks about user interaction in the sense that it says there shouldn't need to be any.   We have in the past talked about how to make that work, since at the very minimum, the arrangement of ethernet ports on a router and the labeling of these connectors constitutes a user interface.   3.3 also talks about a shared key, but doesn't say how that's provided.   We talked about this during the early discussions about the architecture document, and I don't think we came to any kind of consensus about how that would work, although I think it was clear to everybody that we needed to figure out some way to identify friend and stranger when it comes to bridging over Wifi.   Some ideas for how to do this were discussed, and sounded good at least to me, so I don't think that's the end of the discussion, but the lack of consensus makes it hard to say anything more in the architecture document.

The bottom line, wearing my working group participant hat, not my AD hat, is that this is going to be an evolutionary process, and things that are unclear now will become clearer later, and can be added to a new version of the architecture document then.   Much as we might wish for it to be the case that the architecture document as written could be the final, perfect version, I don't think we are in a position to achieve that yet.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 19 Jun 2013 19:44:27 +0200

> I suggested to consider [...] TRILL.

(giggle)

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jun 2013 14:06:42 -0400

>> I suggested to consider [...] TRILL.

He's not the only person to think of it.   If not to use it directly, to consider its use of IS-IS.

---

From: "Mark Baugher (mbaugher)" <[email-masked]>
Date: Wed, 19 Jun 2013 18:39:45 +0000

On Jun 19, 2013, at 12:58 AM, Mikael Abrahamsson <[email-masked]>
 wrote:

> There are a lot of use-cases where it would be beneficial to have things work well regardless of topology for devices being connected. 

And some where it is not: A security service might not place sensors or actuators on the common home LAN owing to common threats like malware, visitors, etc.  This is a routable homenet use case.

Mark

---

From: "Mark Baugher (mbaugher)" <[email-masked]>
Date: Wed, 19 Jun 2013 18:48:56 +0000

> I'm just pessimistic about it getting anywhere deployed widely.

Depends on how IoT applications and other new services appear on the home network or don't appear - in which case there may be little need for routing.  But today's bridged home network (SSID+ethernet ports) is not well suited to services that need network separation.

After all, why are we introducing multiple routers in the home anyway?  In my case its because I have a teleworking service, others may have a security service or smart meter, etc.
  
> There's millions or billions of them. They usually use cheap routers with limited resources. And I don't think that is going to change anywhere in the near future. So while technically a full-blown…

Home routers are subject to Moore's law and they will continue to grow in speed and memory that can increasingly support routing, VPN, 802.1x and other services.

Mark

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 20 Jun 2013 04:23:14 +0200 (CEST)

On Wed, 19 Jun 2013, Mark Baugher (mbaugher) wrote:

> And some where it is not: A security service might not place sensors or 
> actuators on the common home LAN owing to common threats like malware, 
> visitors, etc.  This is a routable homenet use case.

Hm, I don't know if I'm misunderstanding you, but just to be clear, I am 
very much *pro* a routed home and this is what I am advocating for.

But anyhow, isn't the correct approach for a sensor manufacturer to make 
sure only devices authorized to talk to it, can talk to it? By means of 
using IPSEC or similar mechanism? Then again, I realise a sensors isn't in 
a great position to handle a few megabits of small packets from Internet.

Can perhaps something like 802.1x be used to be placed the device into 
different vlans and/or different secured routing domains within the home 
(or a configurable firewall policy in the homenet router depending on some 
criteria that is configurable). I need to think about this, it's an 
interesting question.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 20 Jun 2013 14:38:04 +0200

> and given wifi, it's really easy even for experts to create.

Could you please explain that?

I was under the impression that a prefix subdelegation is always for
a longer prefix than the one it was delegated from, so at each hop the
prefix gets longer.  A loop would imply that a prefix is strictly
longer than itself.

(Of course we want a proper routing protocol, whether DHCP-PD can
handle routing topologies or not, but I'd hope that DHCP-PD is at
least as good as STP.)

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Jun 2013 09:01:36 -0400

> handle routing topologies or not, but I'd hope that DHCP-PD is at

The correct way to do PD in a homenet, if you want to do PD, is to have a single router doing delegation, and all the other routers on the network relaying to that router if they are not directly connected to a link to which that router is also connected.   So while what you say above is true, it doesn't mean what you think it means, because all delegations are coming from a single source.

How a routing loop happens in this model is another question, of course.   Suppose I connect my network up like this:

   -D--
   V  V
A->B->C
^-----V

A knows how to get to the outside world directly.   B knows how to get to the outside world through A or C or D.   C knows how to get to the outside world through B or through A or D.   D knows how to get to the outside world through B or C.   So now you can have a case where if routing decisions are deterministic, and happen the wrong way, you can have a packet looping through D until the TTL runs out, for instance.

Of course, it would be straightforward to detect this situation, and we could invent a new mechanism to do it, but we already have mechanisms for doing it (e.g., IS-IS), so why not use them?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 20 Jun 2013 15:10:59 +0200

> A knows how to get to the outside world directly.  B knows how to
> get to the outside world through A or C or D.

You've lost me here.  B got its prefix delegation from A, so B's
default route points at A, no?

> Of course, it would be straightforward to detect this situation, and
> we could invent a new mechanism to do it, but we already have
> mechanisms for doing it (e.g., IS-IS), so why not use them?

I think everyone here is convinced that it's a good idea to be using
a real routing protocol to communicate between routers, but that's
quite orthogonal to the (purely theoretical) question of whether
a DHCP-PD-based topology causes persistent routing loops.

-- Juliusz

---

From: Tim Chown <[email-masked]>
Date: Thu, 20 Jun 2013 14:24:16 +0100

> a DHCP-PD-based topology causes persistent routing loops.

So the homenet-arch text splits out the routing functionality (which doesn't strictly require a routing protocol) from the prefix assignment functionality. In hipnet, there is no routing protocol, you have cascaded DHCP-PD with default route up, more specifics down. In zOSPF, prefixes are assigned as per draft-arkko-homenet-prefix-assignment-04. 

My question is whether there is any specific text suggested for homenet-arch from this discussion. The previous suggestions from Ole are already noted.

Tim

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Jun 2013 15:25:30 +0200

Le 20/06/2013 14:38, Juliusz Chroboczek a écrit :
>> It can not deal with loops: I see them regularly in people's small
>> offices, and given wifi, it's really easy even for experts to
>> create.
>
>  a longer prefix than the one it was delegated from,

Not necessarily.  It is possible to configure DHCPv6 PD such that to
delegate whatever prefix compared to already owned, or compared to other
delegated prefix: equal, longer, shorter or completely different.  It is
however important that when DHCPv6 delegates something, the routes in
the routing table entries of intermediate machines be set up accordingly.

Loops appear in the route set up phase (which is a different software
than what typically DHCPv6 PD software does).

'Loops' is what one cries about when noticing (1) circling packets after
delegation and route setup, or (2) same prefix delegated to different
places, or (3) packet storms.

Hop Limit is a field in each IP packet decremented at each forwarding
step, and dropped when 0 - a good tool helping not fear loops.

Other tools exist.  One would need however a good interface between the
DHCPv6-PD software and that other dynamic routing protocol.

> so at each hop the prefix gets longer.  A loop would imply that a
> prefix is strictly longer than itself.
>

I am not sure what is STP.

Last time I checked long ago DHCPv6-PD would not do any routing table
management (not insert nor remove entries).  This is an operation that
is needed at least at Relay, upon delegation (insert an entry for the
delegated  prefix, and remove it when no longer delegated).

Alex

>
> -- Juliusz _______________________________________________ homenet
> mailing list [email-masked]

---

From: Teco Boot <[email-masked]>
Date: Thu, 20 Jun 2013 16:29:28 +0200

Op 20 jun. 2013, om 15:01 heeft Ted Lemon <[email-masked]> het volgende geschreven:
> 
> The correct way to do PD in a homenet, if you want to do PD, is to have a single router doing delegation, and all the other routers on the network relaying to that router if they are not directly connected to a link to which that router is also connected. 

Better: a single router doing delegation for a prefix_delegated_by_ISP. In practice, it would be the router with the link to the ISP.

Teco

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Jun 2013 10:37:12 -0400

> Better: a single router doing delegation for a prefix_delegated_by_ISP. In practice, it would be the router with the link to the ISP.

I don't see a difference between what you said and what I said, so I think we are in violent agreement.   If you were trying to say something different than what you understood me to be saying, could you try again?   :}

---

From: Ole Troan <[email-masked]>
Date: Thu, 20 Jun 2013 16:43:24 +0200

> I don't see a difference between what you said and what I said, so I think we are in violent agreement.   If you were trying to say something different than what you understood me to be saying, cou…

Teco's case you would have multiple routers delegated prefixes, one for each ISP in the multi-homed case.
if I understand your suggestion correctly, you would have one router elected to do the delegation.
you'd still need to build a spanning tree of DHCP relays in the network. and preferably you'd need to integrate
the PD server with the routing protocol topology database to avoid duplicate assignments on shared links.
in Teco's case DHCP has to be changed to deal with multiple sources of information. in your case you'd need some sort of protocol between edge routers to collate the information to delegate.

cheers,
Ole

---

From: "Mark Baugher (mbaugher)" <[email-masked]>
Date: Thu, 20 Jun 2013 15:01:06 +0000

On Jun 19, 2013, at 7:23 PM, Mikael Abrahamsson <[email-masked]>
 wrote:

> Hm, I don't know if I'm misunderstanding you, but just to be clear, I am very much *pro* a routed home and this is what I am advocating for.

Sorry, I am agreeing with you and adding that there are some use cases where apps are sensitive to topology, like home security.

> 
> But anyhow, isn't the correct approach for a sensor manufacturer to make sure only devices authorized to talk to it, can talk to it? By means of using IPSEC or similar mechanism? Then again, I realise a sensors isn't in a great position to handle a few megabits of small packets from Internet.

I have seen retail home monitoring applications that plug into the home LAN.  Layer 3-7 security could be added and probably should be, but it would be better not to have critical flows on the common home network.

> 
> Can perhaps something like 802.1x be used to be placed the device into different vlans and/or different secured routing domains within the home (or a configurable firewall policy in the homenet router depending on some criteria that is configurable). I need to think about this, it's an interesting question.

Yes, but we are not longer in the auto-configured, DIY case for home services.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Jun 2013 12:32:58 -0400

> if I understand your suggestion correctly, you would have one router elected to do the delegation.

No, I meant the same thing.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Jun 2013 09:39:43 -0700

On Thu, Jun 20, 2013 at 6:01 AM, Ted Lemon <[email-masked]> wrote:

> The correct way to do PD in a homenet
>

There is no correct way to do PD in a homenet if you want to be able to
change the topology. Specifically, if the One Router acting as a DHCPv6
server is unplugged or crashes, everything breaks.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Jun 2013 12:34:49 -0700

> - the firewall text appears appropriate, though some could be pruned without changing the tone/balance

Wait a minute: it is an extraordinary claim that the current practice of putting
hosts on home network behind firewalls is obsolete. There needs to be justification
for that claim and I haven't heard it here, and it most certainly isn't in the document.

Mike

---

From: "Mark Baugher (mbaugher)" <[email-masked]>
Date: Thu, 20 Jun 2013 19:50:42 +0000

On Jun 20, 2013, at 12:34 PM, Michael Thomas <[email-masked]>
 wrote:

> hosts on home network behind firewalls is obsolete.

Here's what the I-D says: "The use of firewalls today, whether a good practice or not, is common practice and whatever protection afforded, even if marginally effective, should not be lost."

Mark
> There needs to be justification

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Jun 2013 12:58:30 -0700

> Here's what the I-D says: "The use of firewalls today, whether a good practice or not, is common practice and whatever protection afforded, even if marginally effective, should not be lost."

Ok, it's the wording that's extremely awkward. This entire section should just be
deleted because it's not furthering any goal, and seems to just be editorializing
somebody's distaste for firewalls without actually saying something needs to be
done. If it's not deleted it should just say:

  "homenet arch recommends that the current practice of putting firewalls on CPE remain."

and leave it at that.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Jun 2013 08:20:43 +1200

>  "homenet arch recommends that the current practice of putting firewalls

The problem with that is that in IPv4 homenets, many people equate
"firewall" with "NAT" and we don't want that to carry over.

Also there is a whole other discussion that we surely don't want in
*this* draft about the best split in firewall functions between
perimeter defence and individual host defences.

Something like

"Clearly all hosts in a homenet must be adequately protected by
built-in security functions, but it is also assumed that all CPEs
will continue to provide appropriate perimeter defence functions
[rfc6204bis]."

   Brian

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Jun 2013 13:22:52 -0700

> will continue to provide appropriate perimeter defence functions

That works for me.

Mike

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 21 Jun 2013 00:38:35 +0200

> They usually use cheap routers with limited resources.

Steven,

The following is run on a WNDR3700v2, which cost €70 when we bought
it.  It is running babeld, ahcpd, the OpenWRT web interface, OpenVPN,
the full NTP daemon, and is streaming topology data to a remote
BabelWeb instance:

  root@omicron:~# free
               total         used         free       shared      buffers
  Mem:         61708        24152        37556            0            0
  -/+ buffers:              24152        37556
  Swap:            0            0            0
  root@omicron:~# df -h /
  Filesystem                Size      Used Available Use% Mounted on
  rootfs                   14.6M      5.5M      9.0M  38% /
  root@omicron:~# uptime
  00:26:18 up 9 days, 10:13,  load average: 0.00, 0.03, 0.04

As you can see, resource limitations are simply not an issue any more,
even in fairly cheap routers.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 21 Jun 2013 01:24:37 +0200

> However a whole separate OSPF or so daemon + routing stack with 100s
> of KB and all the inherent logic just for a few very advanced
> usecases?

$ size babeld
   text    data     bss     dec     hex filename
  82262    1288    1408   84958   14bde babeld
$ ps l $(cat /var/run/babeld.pid)
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
5     0  5953     1  20   0   8396   576 poll_s Ss   ?          0:19 babeld -D -

That's 50 kB of flash (after compression) and half a meg of RAM.  I'm
pretty sure a well-done implementation of OSPFv3 can be within an
order of magnitude of that.

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Jun 2013 20:09:28 -0400

Juliusz Chroboczek <[email-masked]> wrote:
    sb> this is also what chained DHCPv6-PD / a hipnet-like solution can do.

    mcr> It can not deal with loops: I see them regularly in people's small
    mcr> offices, and given wifi, it's really easy even for experts to create.

    juliusz> Could you please explain that?

    juliusz> I was under the impression that a prefix subdelegation is always
    juliusz> for a longer prefix than the one it was delegated from, so at
    juliusz> each hop the prefix gets longer.  A loop would imply that a
    juliusz> prefix is strictly longer than itself.

Given the scenario:

ISP1      ISP2
  \        /
  CPE1   CPE2___
   \      /     \
   ~~~~~~~ wifi  \WIRE
      |           |
     CPE3         |
      |           |
      \------------

PD will have CPE3 get a prefix from...? CPE1? CPE2 (via WIFI) and CPE3 (via wired).
If you look at the wires, it looks like CPE3 is simply plugged into CPE2. But
the wires you can't see help too.  Why did you buy CPE3?  

Well, how about so that you'd have wifi coverage in the upstairs.
(CPE3 can easily see CPE2 and CPE1, but a tablet in your bed can't)

In order for CableLabsHome to be augmented to support multiple ISPs, CPE3 has
to get PDs from all possible "uplinks".   

Should CPE1 now also ask for a prefix (from ISP2) from CPE3, which now looks
like an uplink to it as well.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Jun 2013 20:12:46 -0400

Mark Baugher (mbaugher) <[email-masked]> wrote:
    >> There are a lot of use-cases where it would be beneficial to have
    >> things work well regardless of topology for devices being connected.

    > visitors, etc.  This is a routable homenet use case.

You don't need to invoke malware...

1) The sensor network doesn't have the bandwidth to support the amount of
   multicast traffic that occurs on the LAN.
2) the sensor network was created before the home owner bought the home,
   and signed up for an ISP.
...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Jun 2013 20:17:10 -0400

> like an uplink to it as well.

Yes.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Jun 2013 17:37:10 -0700

> even in fairly cheap routers.

I think probably too many of us here were traumatized by the bad old
days when we were sneered at for wasting a whole 128kb of ram.

What I really want is my router(s) to be the always-on-therefore-lets-make-use-of-it
hub for my house that does all kinds of other non-routing related chores. In fact,
I want it to look like this:

http://headlessandroid.blogspot.com/

Mike

---

From: "Leddy, John" <[email-masked]>
Date: Fri, 21 Jun 2013 01:04:49 +0000

My personal opinion is that HipNet or PD delegation does not work in an
arbitrary topology with multiple service providers.

I also find it hard to believe that you can't build a tree out of a mesh
infrastructure, though, yes there will be wasted connectivity.

I thought this was what HomeNet was supposed to figure out?

There is the issue of the normal home (getting more complex) and issues of
multiple NAT's in V4.

Providers are putting more services and GW boxes into homes, having them
work well with CE devices would be good as more services run over them.

I see HipNet as an IPV4 solution using IPV6, rather than an IPV6 solution.
 I'm all for HomeNet, go.

My fear is that we will end up with a flat L2 home, and when HomeNet shows
up, it will be a massive change to think about sub netting.

There is also the thread of thought that everything goes to the "cloud",
virtual CPE, which almost requires L2 flat homes.

A solution to this conflict would be to include V4 into HomeNet or embrace
HipNet as a transition technology.

John

---

From: Teco Boot <[email-masked]>
Date: Fri, 21 Jun 2013 08:24:39 +0200

> No, I meant the same thing.

Great.

Thanks, Teco

---

From: Teco Boot <[email-masked]>
Date: Fri, 21 Jun 2013 08:43:42 +0200

Op 20 jun. 2013, om 18:39 heeft Lorenzo Colitti <[email-masked]> het volgende geschreven:

> There is no correct way to do PD in a homenet if you want to be able to change the topology. Specifically, if the One Router acting as a DHCPv6 server is unplugged or crashes, everything breaks. 

Only the DHCPv6 service for delegated prefix for that ISP breaks. Network should inform nodes the gateway for that prefix is down. So almost all continues to work fine.

ULA is a special case. Each ULA Global ID would be served by One Router. I see a need for a ULA DHCP server election mechanism. A router would stand up if no other router serving ULA is in place. Preferable a single ULA serving router and single Global ID. If more ULA Global IDs, nothing should break.

Teco

---

From: Ralph Droms <[email-masked]>
Date: Fri, 21 Jun 2013 08:11:47 -0400

On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon <[email-masked]> wrote:

> I find this text in the document a bit problematic too.   I don't think it's actually reasonably practical to do any such determination.

Perhaps it should be explicitly called out as an open question in the architecture document?

>  The only practical source of subnet sizing is the size of the smallest prefix we got from an ISP.   I guess there are some ideas we could suggest, but they look more like solutions than architecture to me.

The delegated prefixes only provide an upper bound.  My concern is that we're assuming routing in the homenet comes from three sources:

1) explicitly desired for a specific goal like privacy or traffic management
2) hardware requirements like unbridgeable L2s or where bridging is for some reason undesirable
3) random placement of devices

1) requires some sort of explicit management while 3) may incur unnecessary complexity.  2) might deserve a little more text in the architecture document so the WG can have a discussion about what can be supported as "undesirable".

> 
> For instance, we could say that for any given router, all non-edge interfaces on that router that are of the same media type should be bridged together into a single subnet.

But here's where routing for a desired property and management comes in ... suppose one of the router ports is to be configured as a separate link for the "office" subnet?  That configuration can't be inferred, I don't think.

>   CeroWRT makes each one its own subnet, which drives me nuts.   This would have the effect that if you plugged a Wifi router's ethernet port into the ethernet port of a CER, the WiFi router's ethernet port would be on the same subnet as the CER's ethernet ports, but the Wifi network would be on its own subnet; hence, routed, not bridged, which I think is desirable.   But does this belong in the architecture document?

I think there needs to be more careful distinction among the three cases I mentioned earlier.  Here, I think you're talking about case 2).

I agree that goals, requirements and problem statements belong in the architecture document, but (mostly) not solutions. 

> 
> Furthermore, it's complicated by the fact that we'd really prefer to avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite possible that people will plug such interfaces together.
>   So we may need to decide very dynamically which interfaces are bridged and which are routed.   Maybe we will have virtual bridged networks on each homenet router for each media type and speed that the router supports, and dynamically connect interfaces that are running at that speed to those bridges, and hope that this works.
> 

Maybe it needs to be cited as an open question?  I'll re-read the document; statements like "we'd really prefer to avoid briding between 10mbps, 100mbps and 1Mbps internet" ought to be made explicit and justified.

> How many subnets is determined by the size of the prefix we are given.   If we get a /64, the whole homenet is going to have to be a single subnet, like it or not.   If we get a /48, we can have a…

There are other considerations beyond the upper limit imposed by the delegated prefix.  Where do we draw the "silly" line?

> 3.3.3 does talk about guest realms, which I think is adequate.   Talking about UI is probably unnecessary, since it's implicit that some UI is needed, and since the text in 3.3.3 isn't nearly suffi…

I'm not suggesting the architecture document needs to describe a UI.  I think more clarity is needed about what is expected to be automated and what requires some form of management intervention (See below for more).

> 
> The beginning of 3.3 talks about user interaction in the sense that it says there shouldn't need to be any.   We have in the past talked about how to make that work, since at the very minimum, the arrangement of ethernet ports on a router and the labeling of these connectors constitutes a user interface.

Yup.  Can it be left as an open question?  Something to the effect of "there is a tension between autonomous operation and control of the network deployment to meet user requirements"?

>   3.3 also talks about a shared key, but doesn't say how that's provided.   We talked about this during the early discussions about the architecture document, and I don't think we came to any kind of consensus about how that would work, although I think it was clear to everybody that we needed to figure out some way to identify friend and stranger when it comes to bridging over Wifi.

And I don't see any discussion of how sorting of devices by type into the network topology actually works.  That is, the logical topology doesn't necessarily match the physical topology, and I don't see any acknowledgment of that issue in the document.

>   Some ideas for how to do this were discussed, and sounded good at least to me, so I don't think that's the end of the discussion, but the lack of consensus makes it hard to say anything more in the architecture document.
> 
> The bottom line, wearing my working group participant hat, not my AD hat, is that this is going to be an evolutionary process, and things that are unclear now will become clearer later, and can be added to a new version of the architecture document then.

I absolutely agree, and I thought Curtis Villamizar made an interesting suggestion about a wiki summary, which evolves as the WG develops specific technologies.  If there is interest, I'll volunteer to extract an initial summary out of the architecture document.

>   Much as we might wish for it to be the case that the architecture document as written could be the final, perfect version, I don't think we are in a position to achieve that yet.
> 

I agree that perfect is the enemy of the good, and draft-ietf-homenet-arch-08 is a good document.  In my opinion, the document would benefit from some more specificity around

---

From: Ralph Droms <[email-masked]>
Date: Fri, 21 Jun 2013 09:54:35 -0400

On Jun 20, 2013, at 8:09 PM 6/20/13, Michael Richardson <[email-masked]> wrote:

> PD will have CPE3 get a prefix from...?

I'm not sure whether you're asking about hierarchical PD (HIPnet) or centralized PD (draft-baker-homenet-prefix-assignment-01).

Section 3..1.2.2 of the latter addresses this issue.  The idea is that CPE3 detects RAs on wifi and WIRE and concludes it does not need to make any PD requests.

Here are three issues to be refined in draft-baker-homenet-prefix-assignment-01 (not all related to the question Michael raises), if there is interest in further development of the specification.

1) What happens if the CPE(s) don't come up in the "correct" order; e.g., suppose CPE3 comes up before CPE1 and CPE2.
2) How does an interior router (in this example, CPE3) in a multi-homed network detect that it needs some but not all prefixes?  From this example, suppose CPE1 has assigned a prefix to wifi but CPE2 has not (for some reason).  How would CPE3 determine it needs a prefix from CPE2 for wifi but not from CPE1?
3) Do CPE1 and CPE2 each do PD for their respective ISPs (requiring changes to the DHCPv6 protocol to allow multiple sources of PD) or do CPE1 and CPE2 agree that CPE1 will hand out all prefixes, and CPE2 delegates all of its prefixes from ISP2 to CPE1?

- Ralph

> CPE1? CPE2 (via WIFI) and CPE3 (via wired).

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Jun 2013 10:39:24 -0400

mcr> Should CPE1 now also ask for a prefix (from ISP2) from CPE3, which
    mcr> now looks like an uplink to it as well.

    tl> Yes.

and now we definitely have a forwarding loop. This is why chained PD does not
solve the problem, and I think is a cul-de-sac architecture.

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Jun 2013 16:54:22 -0400

In message <[email-masked]>
 
> of whether the Homenet group wishes to promote the use of OSPF.

EIGRP is a proprietary protocol, protected by a patent and implemented
by a single vendor (AFAIK).  RIP2 is patent free but nearly dead.

EIGRP, RIP2, and BGP are distance vector (BGP is actually path vector)
and therefore do not give a consistent view of the topology.  BGP
doesn't yield any view at all of a network's internal topology.

BGP is not an appropriate protocol for use as an Interior Gateway
Protocol (IGP).  Deployments which use BGP rely on an IGP to provide
internal topology and reachability.  The IGP in all major providers is
a link state protocol (OSPF or ISIS).  A tiny number of providers that
are foolish enough to lock themselves into a single vendor may use
EIGRP as their IGP (but its zero among the big boys).  Use of RIP2
among providers is zero AFAIK.

I would say that not only would BGP experts object to the statement
above that started this thread, but anyone with a clue about how BGP
is used would object.

Lets leave the text as-is.  It is accurate given that the obvious
context is an interior routing protocol.

We need not consider homenets running BGP at all.  Networks carrying
global routes would need to run BGP, but not as their IGP, and these
networks would not be homenets or sohos or small business.

Curtis

---

From: Dave Taht <[email-masked]>
Date: Fri, 21 Jun 2013 14:24:11 -0700

On Fri, Jun 21, 2013 at 1:54 PM, Curtis Villamizar
<[email-masked]> wrote:
> and therefore do not give a consistent view of the topology.

I take it nobody here is paying any attention to olsr v2, which at
least has hope as towards a viable metric for wireless.

http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/

and also nobody here is paying attention to batman-adv which is both
deployed and available in the linux kernel...

both of these have a consistent view of the topology for some values
of consistent.

There aint nothing wrong with a hybrid approach either, towards
announcing that "I need prefixes" - there is very little stopping any
routing protocol of any sort from announcing that, and getting it, if
that's what you want.

With sufficient spare prefixes a network can have a large degree of
"inconsistency" towards its outlook towards gaining prefixes.

>BGP

This is generally not a discussion about what providers use. A
discussion about what small business uses might be relevant.

My own objections are largely rooted in the need for a viable protocol
over wireless networks. Period. Prove you have a routing viable
protocol for wireless networks and embed a prefix distribution
mechanism in it if you like. Dragging in an entire routing protocol
in, in  support of the prefix mechanism problem is the wrong way
'round.

aside: Most older protocols treat ipv6 and ipv4 separately, often with
separate daemons, and packet types. I'm not particularly fond of that
approach.

> context is an interior routing protocol.

I've kind of lost in this thread what text you are referring to now.

> networks would not be homenets or sohos or small business.

I would rather like multihoming to work in soho and small business.

-- 
Dave Täht

---

From: Dave Taht <[email-masked]>
Date: Fri, 21 Jun 2013 15:04:56 -0700

>> For instance, we could say that for any given router, all non-edge interfaces on that router that are of the same media type should be bridged together into a single subnet.

My definition of media type would treat 2.4ghz and 5.x ghz wireless
differently. does yours?

> But here's where routing for a desired property and management comes in ... suppose one of the router ports is to be configured as a separate link for the "office" subnet?  That configuration can't…

Happens all the time.

>
>>   CeroWRT makes each one its own subnet, which drives me nuts.

Not clear to me which part of that drives you nuts. In part CeroWrt's
purpose is to expose problems with ideas by putting them out there
annoyingly. :)

(The original reason for routing rather than bridging networks in cero
was that we wanted to be able to analyze the effects of routing vs
bridging on wireless. The results of bridging gigE to 2.4ghz are
generally pretty dismal. IPv6 also uses much more multicast than
ipv4.)

Along the way we gained insight into problems with commonly used
protocols like mdns, upnp, dnssdd, windows filesharing, etc. Some of
which have been solved, some of which have fixes in progress, others
are unsolvable, all are documented publicly on the mailing list, wiki
and issues database. Security is also a problem. Etc.

If this group would like the reality based list, I can create a rather
large list of hyperlinks at this point.

The most recent example is the one with problems with windows
filesharing induced by routing:
https://lists.bufferbloat.net/pipermail/bloat/2013-June/001577.html
and successful resolution:

https://lists.bufferbloat.net/pipermail/cerowrt-devel/2013-June/001321.html

It certainly would be nice for people here to setup more homenet-like
setups to get a grip for common protocols that have issues in routed
environments. I don't setup networks like the yurtlab (86 prefixes)

http://pastebin.com/K8g5TyXS

out of any innate love for S&M.

The thing that drives me nuts here is not the prefix distribution
problem (which is 2 sed commands away per router, once, assuming
stable prefixes) but the the naming problems. I'd like to be able to
get to the printer at the office... but there's now a separate group
for solving that.

>This would have the effect that if you plugged a Wifi router's ethernet port into the ethernet port of a CER, the WiFi router's ethernet port would be on the same subnet as the CER's ethernet ports, but the Wifi network would be on its own subnet; hence, routed, not bridged, which I think is desirable.   But does this belong in the architecture document?

I like the "directionless" feature of hipnet.

I'd like it very much if there was a way to distinguish between a
master and slave router out of the box for both ipv4 and ivp6. If you
plug two routers together on their bridge, they end up competing, if
you plug the uplink of one into the other, you get nat, and either
way, if they are both on 192.168.1.1, weird things happen.

>> Furthermore, it's complicated by the fact that we'd really prefer to avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite possible that people will plug such interfaces togethe…

wireless issue noted above. Am I the only one in this group that
actually has the vast majority of devices in home and office wireless?
Is there anybody here that doesn't think that the vast majority of
devices in the home will be wireless?

> Maybe it needs to be cited as an open question?  I'll re-read the document; statements like "we'd really prefer to avoid briding between 10mbps, 100mbps and 1Mbps internet" ought to be made explici…

see above.

>> This leads to a separate question that is also interesting: what if we are multihomed, and one ISP gives us lots of prefix, and the other ISP gives us a /64?   Do we bridge, to accommodate the chi…

I note that openwrt merely gives up and relays ips off a single /64 if
it has to.

-- 
Dave Täht

---

From: Mark Townsley <[email-masked]>
Date: Sat, 22 Jun 2013 13:28:31 +0200

Hi John, nice to hear from you. With my chair hat on, I'd like to clarify one thing here.

> HipNet as a transition technology.

"IP Version Agnostic" work is (and has always been) within scope of the WG. Meaning, we are chartered to define solutions that could work in IPv4 and IPv6 whenever possible, as long as we are not making compromises in IPv6 due to the existing state of IPv4 (as an extreme example, we wouldn't include IPv6 NAPT just because IPv4 has it). That's another way of saying work MUST be incremental to the ultimate IPv6 solution, and SHOULD be applicable to IPv4.

For homenet to embrace hipnet as a transition technology, it needs to show that it does in fact provide transition rather than a stumbling block to the full IPv6 solution. Ray has asked for that from the authors already. But in terms of your first option (including IPv4 in Homenet), as long as IPv4 is not holding up the ultimate IPv6 design, it's already in scope in for Homenet today.

- Mark

---

From: Ray Hunter <[email-masked]>
Date: Sat, 22 Jun 2013 19:14:52 +0200

> My definition of media type would treat 2.4ghz and 5.x ghz wireless
Bridging between the two could be problematic, yes.

> annoyingly. 
Agreed. Namespace (and service discovery) will likely remain a
significant challenge with competing architectures, never mind
implementations.

> wireless issue noted above.
I agree. AFAIK we do NOT have large scale reference deployments of
common IGP's where wireless is used as a connector between multiple routers.

Selecting Designated Router and Backup Designated Router in OSPF and
Designated Intermediate System in IS-IS is NOT trivial especially when
not all of the routers are within radio range of a common router. In
fact I think we may well be missing a trick here, and we may need some
form of mesh under network, at least between the routers connected via a
common wireless link but where they are not all mutually within range of
each other. Wireless to wireless bridging / repeating also seems to be
highly proprietary and problematic.

>  Am I the only one in this group that
No.

> devices in the home will be wireless?
Not me.

> <snip>

---

From: Acee Lindem <[email-masked]>
Date: Sat, 22 Jun 2013 19:30:17 +0000

There seems to be a fundamental disagreement here in terms of requirements. With respect to wireless, we all agree that the home will include a large number of wireless devices. However, I do not believe all these devices will participate in the routing topology. Rather, there will be a small finite number of routers with fixed and wireless connectivity that form the home routing infrastructure. I do not believe the requirement is for a MANET network while those active in the MANET WG take this as given. Until we agree or agree to disagree on this requirement, we will have wildly divergent opinions on the architecture with respect to routing. 
Thanks
Acee

---

From: Ray Hunter <[email-masked]>
Date: Sat, 22 Jun 2013 22:05:35 +0200

> Acee Lindem <mailto:[email-masked]>
> 22 June 2013 21:30
> There seems to be a fundamental disagreement here in terms of
> requirements.
possibly.

> With respect to wireless, we all agree that the home will include a
> large number of wireless devices.
agree.
> However, I do not believe all these devices will participate in the
> routing topology.
agreed, almost certainly not all. Especially not static sensors.

> Rather, there will be a small finite number of routers with fixed and
> wireless connectivity that form the home routing infrastructure.

Right. But even if you have 4 or 5 routers (one per room or per floor)
there's a strong chance that they won't all be in mutual radio contact.

So then you probably cannot assume all 4 or 5 of them are on a single
shared subnet using the traditional OSPF or IS IS designated router to
distribute routing information to all the on-link neighbors.

Add to that scenario auto-prefix distribution. How do you establish and
manage neighbor adjacencies versus subnets/ prefixes?

Or do you presume that the homenet routers will be contiguously
connected via wires, and there's no wireless router-router connections?

> I do not believe the requirement is for a MANET network while those
> active in the MANET WG take this as given.

I never said there'd be a MANET, but we might need to consider that
there'll be point to point wireless links that act as active adjacencies
between 2 routers and that there'll be no alternative wired link between
these routers, whilst at the same time those wireless interfaces are
serving local end nodes within range.

RFC 5820 could be of help in that situation to maintain router-router
adjacencies as point to point links (without necessarily invoking all of
MANET requirements for an ad hoc network of many mobile nodes). I don't
know of any IS IS equivalent. Otherwise I think we might very well get
into problems with repeaters and packet loss.

> Until we agree or agree to disagree on this requirement, we will have
> wildly divergent opinions on the architecture with respect to routing.
> Thanks
> Acee
>
> Ray Hunter <mailto:[email-masked]>
> 22 June 2013 19:14
> Dave Taht wrote:
> ------------------------------------------------------------------------

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 22 Jun 2013 22:23:57 +0200

> requirements. With respect to wireless, we all agree that the home
> will include a large number of wireless devices. However, I do not
> believe all these devices will participate in the routing
> topology.

AFAICT, nobody on this list has suggested otherwise.

I'm confused.  Whose statement exactly are you reacting to?

-- Juliusz

---

From: Acee Lindem <[email-masked]>
Date: Sat, 22 Jun 2013 21:20:43 +0000

> connected via wires, and there's no wireless router-router connections?

I'd envision that all home network routers would be connected via wires or wireless but for topology changes to be infrequent. I don't envision a home network having the same dynamics as a MANET. 
With respect to wireless router-to-router connections, if you cannot assume mutual radio contact on the same wireless network, we could use P2MP as the default topology to solve the router-to-router problem. However, this assumption would break the broadcast model as well for hosts since basic protocols like ND and ARP assume a broadcast network. 

> serving local end nodes within range.

Okay. 

> into problems with repeaters and packet loss.

RFC 5820 is specifically to deal with the dynamic topologies and flooding scale challenges associated with a MANET network. I don't see it as being applicable to the home network. 

Thanks,
Acee

---

From: Andrew McGregor <[email-masked]>
Date: Sun, 23 Jun 2013 15:07:38 +1000

I actually think that some MANET technologies are applicable here... I
don't recall what happened to its standardisation process, but wOSPF has a
lot of nice properties here, not least being that we have homenet
considering an OSPF based solution, and wOSPF provides the necessary
mechanics to deal with a wireless mesh.  This is also a positive for BABEL,
it being primarily intended for mesh.

Bear in mind that topology updates in fixed wireless mesh mostly come from
statistics; you are never going to have 100% reachability probability for
your HELLOs (much less than that if they are multicast), and therefore
every now and again there will be false unreachability detections.
 Secondly, wireless channels, even fixed ones, are subject to time
variability due to moving reflective objects in the environment; homenet
really ought to work on wireless even when there's a street right outside
the window, no?  This implies taking the wireless mesh case as the default;
the protocols will definitely work on wired, and will tend to continue to
work even on badly degraded wired links.

On Sun, Jun 23, 2013 at 7:20 AM, Acee Lindem <[email-masked]>wrote:

> I'd envision that all home network routers would be connected via wires or
> wireless but for topology changes to be infrequent. I don't envision a home
> network having the same dynamics as a MANET.
> With respect to wireless router-to-router connections, if you cannot
> assume mutual radio contact on the same wireless network, we could use P2MP
> as the default topology to solve the router-to-router problem. However,
> this assumption would break the broadcast model as well for hosts since
> basic protocols like ND and ARP assume a broadcast network.
>
>
> >
> >
> RFC 5820 is specifically to deal with the dynamic topologies and flooding
> scale challenges associated with a MANET network. I don't see it as being
> applicable to the home network.
>
> Thanks,
> Acee
>
>
> >
> >
> >
> >>>>>> The document makes no mention of *how* a largest practical subnet
> architecture might be achieved.  There should be some requirement that
> devices be capable of acting as either a bridge or a router (or a mix of
> both), and that devices should bridge unless routing is determined
> necessary.
> >>>>> I find this text in the document a bit problematic too.   I don't
> think it's actually reasonably practical to do any such determination.
> >>>>> The only practical source of subnet sizing is the size of the
> smallest prefix we got from an ISP.   I guess there are some ideas we could
> suggest, but they look more like solutions than architecture to me.
> >>>> The delegated prefixes only provide an upper bound.  My concern is
> that we're assuming routing in the homenet comes from three sources:
> >>>>
> >>>> 1) requires some sort of explicit management while 3) may incur
> unnecessary complexity.  2) might deserve a little more text in the
> architecture document so the WG can have a discussion about what can be
> supported as "undesirable".
> >>>>
> >>>>> For instance, we could say that for any given router, all non-edge
> interfaces on that router that are of the same media type should be bridged
> together into a single subnet.
> >>>> But here's where routing for a desired property and management comes
> in ... suppose one of the router ports is to be configured as a separate
> link for the "office" subnet?  That configuration can't be inferred, I
> don't think.
> >>> Happens all the time.
> >>>
> >>>> This would have the effect that if you plugged a Wifi router's
> ethernet port into the ethernet port of a CER, the WiFi router's ethernet
> port would be on the same subnet as the CER's ethernet ports, but the Wifi
> network would be on its own subnet; hence, routed, not bridged, which I
> think is desirable.   But does this belong in the architecture document?
> >>>> I think there needs to be more careful distinction among the three
> cases I mentioned earlier.  Here, I think you're talking about case 2).
> >>>>
> >>>> I agree that goals, requirements and problem statements belong in the
> architecture document, but (mostly) not solutions.
> >>>>
> >>>>> Furthermore, it's complicated by the fact that we'd really prefer to
> avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite
> possible that people will plug such interfaces together.
> >>>>>  So we may need to decide very dynamically which interfaces are
> bridged and which are routed.   Maybe we will have virtual bridged networks
> on each homenet router for each media type and speed that the router
> supports, and dynamically connect interfaces that are running at that speed
> to those bridges, and hope that this works.
> >>>>>
> >>>>> I don't think we've visited this issue thoroughly enough to make
> statements about it in the architecture document.
> >>>> Maybe it needs to be cited as an open question?  I'll re-read the
> document; statements like "we'd really prefer to avoid briding between
> 10mbps, 100mbps and 1Mbps internet" ought to be made explicit and justified.
> >>> see above.
> >>>
> >>> <snip>
> >>

---

From: Henning Rogge <[email-masked]>
Date: Sun, 23 Jun 2013 10:19:56 +0200

On Sun, Jun 23, 2013 at 7:07 AM, Andrew McGregor <[email-masked]> wrote:
> I actually think that some MANET technologies are applicable here... I don't
> recall what happened to its standardisation process, but wOSPF has a lot of
> nice properties here, not least being that we have homenet considering an
> OSPF based solution, and wOSPF provides the necessary mechanics to deal with
> a wireless mesh.  This is also a positive for BABEL, it being primarily
> intended for mesh.

Is there a reason not to consider using OLSRv2 as the routing protocol
if you are running a mesh?

Henning Rogge

----
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Acee Lindem <[email-masked]>
Date: Sun, 23 Jun 2013 10:37:52 +0000

On Jun 23, 2013, at 1:07 AM, Andrew McGregor wrote:

I actually think that some MANET technologies are applicable here... I don't recall what happened to its standardisation process, but wOSPF has a lot of nice properties here, not least being that we have homenet considering an OSPF based solution, and wOSPF provides the necessary mechanics to deal with a wireless mesh.  This is also a positive for BABEL, it being primarily intended for mesh.

By wOSPF, I guess you mean the OSPF MANET options. I believe RFC 5820 and RFC 5614 have seen some usage.

Bear in mind that topology updates in fixed wireless mesh mostly come from statistics; you are never going to have 100% reachability probability for your HELLOs (much less than that if they are multicast), and therefore every now and again there will be false unreachability detections.  Secondly, wireless channels, even fixed ones, are subject to time variability due to moving reflective objects in the environment; homenet really ought to work on wireless even when there's a street right outside the window, no?  This implies taking the wireless mesh case as the default; the protocols will definitely work on wired, and will tend to continue to work even on badly degraded wired links.

The problem with using a mesh topology by default is that it doesn't handle the non-routers very well unless they also participate in the mesh and have their host addresses advertised independently like the routers. At least this is the case for OSPF P2MP and the OSPF MANET variants - the assumption is that all devices connecting to the mesh form routing protocol adjacencies.

Thanks,
Acee

On Sun, Jun 23, 2013 at 7:20 AM, Acee Lindem <[email-masked]<mailto:[email-masked]>> wrote:

On Jun 22, 2013, at 4:05 PM, Ray Hunter wrote:

>> Acee Lindem <mailto:[email-masked]<mailto:[email-masked]>>
>> 22 June 2013 21:30

Okay.

Thanks,
Acee

>> Ray Hunter <mailto:[email-masked]<mailto:[email-masked]>>
>> 22 June 2013 19:14
>> Dave Taht wrote:
>>> On Fri, Jun 21, 2013 at 5:11 AM, Ralph Droms <[email-masked]<mailto:[email-masked]>> wrote:
>>>> On Jun 19, 2013, at 1:39 PM 6/19/13, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>>> On Jun 17, 2013, at 4:13 PM, Ralph Droms <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

---

From: Andrew McGregor <[email-masked]>
Date: Sun, 23 Jun 2013 21:24:26 +1000

So, I believe you could do this: use one SSID for meshing routers and a
different one for clients (possibly hiding the mesh from the clients to
avoid end-user confusion).

On Sun, Jun 23, 2013 at 8:37 PM, Acee Lindem <[email-masked]>wrote:

>  Bear in mind that topology updates in fixed wireless mesh mostly come
> from statistics; you are never going to have 100% reachability probability
> for your HELLOs (much less than that if they are multicast), and therefore
>  The problem with using a mesh topology by default is that it doesn't
> handle the non-routers very well unless they also participate in the mesh
> and have their host addresses advertised independently like the routers. At
> least this is the case for OSPF P2MP and the OSPF MANET variants - the
> assumption is that all devices connecting to the mesh form routing protocol
> adjacencies.
>
>  Thanks,
> Acee
>
>
>
>
>
>>  I'd envision that all home network routers would be connected via wires
>> or wireless but for topology changes to be infrequent. I don't envision a
>> home network having the same dynamics as a MANET.
>>  RFC 5820 is specifically to deal with the dynamic topologies and
>> flooding scale challenges associated with a MANET network. I don't see it
>> as being applicable to the home network.
>>
>> Thanks,
>> Acee
>>
>>
>> >
>> >
>> >
>> >>>> I agree that goals, requirements and problem statements belong in
>> the architecture document, but (mostly) not solutions.
>> >>>>
>> >>>>> Furthermore, it's complicated by the fact that we'd really prefer
>> to avoid briding between 10mbps, 100mbps and 1Mbps internet, and it's quite

---

From: Acee Lindem <[email-masked]>
Date: Sun, 23 Jun 2013 15:38:26 +0000

There is room for innovation here and I agree that one could come up with a model to support this. However, I'm not ready to take it as a requirement for an auto-configured homenet since the Wi-Fi broadcast network model has heretofore served us quite well.
Acee
On Jun 23, 2013, at 7:24 AM, Andrew McGregor wrote:

So, I believe you could do this: use one SSID for meshing routers and a different one for clients (possibly hiding the mesh from the clients to avoid end-user confusion).

On Sun, Jun 23, 2013 at 8:37 PM, Acee Lindem <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Acee

Okay.

Thanks,
Acee

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Jun 2013 12:18:44 -0400

There's been brief mention of the WiFi infrastructure problem for the homenet during this post-last-call conversation, but I don't think we drew a conclusion, and indeed some of what was said seems to suggest that we aren't addressing the issue.

Let's consider the following scenario: I have a wired infrastructure that connects my home and garage.   The home and garage can't all be served by the same Wifi AP.   I want to set up WiFi APs so that I can wander around between the various parts of my home, as well as outdoors, and have good WiFi connectivity in all of these locations, without expensive handoffs and without changing subnets (which would break connections, e.g. SIP calls, ssh sessions, etc).

There are a variety of ways of addressing this problem, and you and Andrew and Ray have touched on them a bit, but I didn't see a clear requirement stated, and I'd like to.   I don't see one in the architecture document either.

The first question is, is this a use case that the Homenet architecture wants to address?   I think the answer is yes, but I don't get the sense that everybody agrees with that, which is why I am asking the question directly.

Second, _can_ we address it, given other assumptions we're making in the architecture, and how?   I've mentioned the wired backbone/wireless AP model, but of course a lot of home environments won't have the luxury of a wired backbone, so we will probably have to do air-to-air infrastructure links to make it work.   What does this look like?

One way to make this work, which someone jokingly alluded to before, would be to have all the APs coexist in a TRILL layer 2.   I'm sure I will attract some rotten tomatoes for that suggestion, but it _would_ work.   Subnetting wouldn't work—it would break connections every time I changed APs.   I am not convinced that making the whole homenet one big bridge is a good answer, but that would work, in the sense of addressing the specific use case I am describing.   Mobile IP would also work, but I don't think it would be practical to set up a Mobile IP infrastructure on a homenet.

It can also be argued that nobody needs this functionality.

Sorry for lobbing this question into an otherwise interesting and related WiFi mesh discussion, but is anybody else thinking about this and/or concerned about this?

---

From: Acee Lindem <[email-masked]>
Date: Sun, 23 Jun 2013 18:18:56 +0000

Ted, 

For this particular problem, I don't think there is a simple solution at layer 3. I think layer 2 bridging is the most straightforward approach to extend the wireless LAN without requiring additional function in every device that connects (e.g., MIP6).  
Thanks,
Acee

---

From: Ray Hunter <[email-masked]>
Date: Sun, 23 Jun 2013 20:21:26 +0200

> Ted Lemon <mailto:[email-masked]>
> 23 June 2013 18:18
> There's been brief mention of the WiFi infrastructure problem for the
> homenet during this post-last-call conversation, but I don't think we
> drew a conclusion, and indeed some of what was said seems to suggest
> that we aren't addressing the issue.
>
> Let's consider the following scenario: I have a wired infrastructure
> that connects my home and garage. The home and garage can't all be
> served by the same Wifi AP. I want to set up WiFi APs so that I can
> wander around between the various parts of my home, as well as
> outdoors, and have good WiFi connectivity in all of these locations,
> without expensive handoffs and without changing subnets (which would
> break connections, e.g. SIP calls, ssh sessions, etc).
>
> There are a variety of ways of addressing this problem, and you and
> Andrew and Ray have touched on them a bit, but I didn't see a clear
> requirement stated, and I'd like to. I don't see one in the
> architecture document either.
>
Sounds like a clear requirement for simple end node to router handoff
over wireless, with session survivability when the end node device
connects via another radio device. That could be expressed in the
architecture without moving on to the "how".

> The first question is, is this a use case that the Homenet
> architecture wants to address? I think the answer is yes, but I don't
> get the sense that everybody agrees with that, which is why I am
> asking the question directly.
Yes. I agree with the requirement (regardless of how it's implemented)

> Second, _can_ we address it, given other assumptions we're making in
> the architecture, and how?

There's a whole load of options:

wireless repeating where there's one AP + wireless extenders to create a
single flat wireless LAN (WDS) = how most home networks work today.
Another would be layer 2 bridging over the entire homenet backbone +
multiple AP's advertising the same SSID on different channels (generally
how most office wifi works today).
Pure routing and disjoint subnets + renumbering the end node would
probably break sessions, and would not work as desired as you rightly
point out.
Another would be carrying a common VLAN for wireless throughout the
homenet over a routed homenet backbone (Integrated Routing and Bridging
in Cisco speak) or bridging over GRE/ other tunnel or other fancy L2/L3
combo that allows a single subnet to remain contiguous when spanning
routed links.
Mobile IP.
MANET.
Mobile end nodes to source / sink sessions from a software loopback
interface and route individual /128's around the Homenet.
Tunnel from the mobile end node to a central router over a point to
point link (like LTE)

Plenty of things to explore, and with varying degrees of end node
involvement, complexity, and survivability.
e.g. sessions over mobile IP requires significant complexity and end
node involvement, but would survive a move between different wireless
technologies.
Bridging requires no end node involvement, is simple within one media
type but problematic between types, and sessions would almost certainly
not survive a move to a different radio technology .
Repeating requires no end node involvement, is generally proprietary,
and sessions would not survive a move to a different radio technology.

> I've mentioned the wired backbone/wireless AP model, but of course a
> lot of home environments won't have the luxury of a wired backbone, so
> we will probably have to do air-to-air infrastructure links to make it
> work. What does this look like?

That to me is a second requirement for wireless, and where we get into a
potential conflict with your first requirement.

For end node - homenet it's only important that you can connect to at
least one device from a set of devices advertising your SSID, and the
end node will generally select the channel with the strongest signal if
there's more than one. It's not relevant that you can simultaneously
reach ALL devices advertising the SSID.

For router - router communication, mutual visibility is very relevant,
as having all routers in a flat LAN will almost certainly seriously
impact common routing protocols being touted. As mentioned previously,
the quality of wireless links will vary substantially over time, as will
adjacencies, even without moving the routers.

>
> One way to make this work, which someone jokingly alluded to before,
> would be to have all the APs coexist in a TRILL layer 2. I'm sure I
> will attract some rotten tomatoes for that suggestion, but it _would_
> work. Subnetting wouldn't work—it would break connections every time I
> changed APs. I am not convinced that making the whole homenet one big
> bridge is a good answer, but that would work, in the sense of
> addressing the specific use case I am describing. Mobile IP would also
> work, but I don't think it would be practical to set up a Mobile IP
> infrastructure on a homenet.
>
> Sorry for lobbing this question into an otherwise interesting and
> related WiFi mesh discussion, but is anybody else thinking about this
> and/or concerned about this?
You've brought up the two wireless use cases that triggered my original
comments, so yes I am concerned that we are neglecting documenting
requirements. Speaking as someone who lives in a reinforced concrete
box, I also think that router to router connectivity over wireless is a
requirement.

regards,
RayH
> 23 June 2013 17:38
> There is room for innovation here and I agree that one could come up
> with a model to support this. However, I'm not ready to take it as a
> requirement for an auto-configured homenet since the Wi-Fi broadcast
> network model has heretofore served us quite well. 
> Acee

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Jun 2013 14:58:30 -0400

> For this particular problem, I don't think there is a simple solution at layer 3. I think layer 2 bridging is the most straightforward approach to extend the wireless LAN without requiring addition…

I think you are right, but it points out an issue with the homenet architecture, because the homenet architecture currently assumes a lot of subnetting, and I think for good reason.   And yet we have what seems to me to be a clear and contradictory requirement for bridging in the case of Wifi infrastructure.

How do we get both?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 23 Jun 2013 23:51:47 +0200

> would be to have all the APs coexist in a TRILL layer 2.  I'm sure
> I will attract some rotten tomatoes for that suggestion, but it
> _would_ work.

I'm starting to be seriously fed up with the TRILL propaganda.  Has
anyone actually made the above to work with TRILL?  With single-radio
wireless routers serving as relays?  Without the silly topology
restrictions required by WDS?

You must realise that we, in the mesh networking community, have been
doing all of the above (and more) for a decade now.  We have a number
of protocols that have been demonstrated, on multiple occasions and by
independent researchers, to work satisfactorily (OLSR-ETX, Babel,
BATMAN).  We spend our copious free time organising regular meetings
to check that this is still the case.

It is difficult not to be annoyed when our work is summarily dismissed
by people who have never flashed a router in their life, but have the
gall to say that running IS-IS at layer 2 with a bunch of tunnels will
actually solve more problems than it will introduce.

Please do refrain from promoting TRILL for this kind of application
until you can provide us with experimental data.  Getting wireless
meshes to work with acceptable efficiency is a little more difficult
than you seem to realise.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Jun 2013 18:36:02 -0400

On Jun 23, 2013, at 5:51 PM, Juliusz Chroboczek <[email-masked]> wrote:
> I'm starting to be seriously fed up with the TRILL propaganda.

Excuse me?   Well, I guess I did predict rotten tomatoes, but you apparently have a very low bar for what qualifies as propaganda.

> Has anyone actually made the above to work with TRILL?

I've never done anything with TRILL except review some documents.   I'm just trying to figure out how to solve the problem, and TRILL does solve the problem, at least on paper.   If there is a better solution, I'm all ears.

> to check that this is still the case.

Well then make your case.   How does what you have done solve the problem I asked about in the homenet architecture?   I am not asking how it works in a wide-area mesh network; I am asking how it works in a homenet.

> actually solve more problems than it will introduce.

Your work is not summarily dismissed.   It is simply not being included in the discussion, because the people who know about it are busy accusing me of propagandizing rather than explaining why their idea is better!

> than you seem to realise.

I didn't propose using TRILL in a wireless mesh.   I proposed using it to connect wireless APs using a wired backbone.   If you think I will get better performance in this scenario by connecting my APs using a wireless mesh, I am interested in hearing how.  But I think this will actually be more difficult than using a wired backbone, because I live in a Passivhaus, and the insulation on the house is foil-backed, so it's very difficult to get radio signals through it; the only radio-transparent part of the house is the bank of windows on the south wall, and the garage is to the east.   And I already have a bunch of cat 6e shielded wires going from the house to the garage, so it's hard to see how any wireless solution you could propose would be easier than using one of them.

Of course this is not a general scenario, but do you see my point?   I'm trying to solve a problem that I don't think is easily solved with wireless, and that I think is relevant to homenet, and that is not currently discussed in the homenet architecture document.   It's quite likely that some sort of layer 2 wireless mesh would work in a different scenario.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 24 Jun 2013 01:56:28 +0200

> Excuse me?

My apologies, Ted.  The tone of my reply was not called for.

> you apparently have a very low bar for what qualifies as propaganda.

> I've never done anything with TRILL except review some documents.

Sorry for the terminology.  By "propaganda" I meant "repeatedly
claiming that TRILL solves the problem without providing any
operational evidence".  (You know, working code and all that.)

Ted, I really think we should be extremely cautious when evaluating
solutions based on the Ruby Goldberg device known as TRILL.

> I didn't propose using TRILL in a wireless mesh.  I proposed using
> it to connect wireless APs using a wired backbone.

You do that using a routing protocol.  I have trouble believing that
moving your routing protocol to layer 2 and hiding it beneath a layer
of tunnelling is going to lead to a robust solution.

> If you think I will get better performance in this scenario by
> connecting my APs using a wireless mesh, I am interested in hearing
> how.  But I think this will actually be more difficult than using
> a wired backbone, because I live in a Passivhaus, and the
> insulation on the house is foil-backed,

Ah, I see the misunderstanding, and it's due to sloppy terminology on
my part.  What we usually call "wireless meshes" are actually
hybrid -- they consist of both wired and wireless links, just like
you'd expect.  The topologies are usually more complex than what you
envision (there are multiple diconnected wired backbones rather than
just one), but we use wired links extensively, either to save radio
spectrum where laying cables is easy, or to cross obstacles.  A wired
link with just two nodes on it is a common way of crossing a wall.

(Babel has explicit provisions for efficient usage of wired links.  In
OSLR-ETX and BATMAN, wired links work, but are not particularly
optimised for.)

> How does what you have done solve the problem I asked about in the
> homenet architecture?

You have a bunch of routers.  You run a routing protocol on all of
them.  Every router announces one or more /64 for its connected links.
You run normal RAs, so that unmodified nodes can connect to the
network.  (Reminder to anyone who forgot -- routers ignore RAs.)

If you don't care about compatibility with normal devices, you run the
routing protocol on each mobile node, but have it filter any routes
except for announcing its own /128 (this is described in RFC 6126
Appendix C).  In effect, you have two kinds of nodes: "legacy" nodes
that use normal routing practices for hosts (RAs, on-link routing
using ND), and mesh nodes, that participate in the routing protocol
although they are not routers.  Legacy nodes must renumber whenever
they roam, while mesh nodes can roam seamlessly at the cost of
introducing an extra /128 into your routing domain and going through
a router in order to reach on-link legacy nodes.

If you want legacy devices to roam seamlessly, it's a little more
messy.  Whenever neighbour discovery (or link sensing?) indicates that
your node has roamed, you have your routers inject a /128 into the
routing domain.  That's going to be slightly less robust (since the
roaming node is not beaconing HELLO packets, so link quality cannot be
estimated).

At a basic level, this will work with any routing protocol as long as
it allows /128 routes.  Of course, if you want the kind of topologies
that we use in mesh networks (forwarding by single-radio nodes, usage
of marginal links when no good links are available), you'll want
a protocol that has the ability to use such topologies, but that's
strictly optional.

I'd like to stress that, except for the hack described in the
next-to-last paragraph, we have implemented and tested the above.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Jun 2013 23:07:41 -0400

The routing mesh you're describing sounds like it would work, and be quite useful, but not for a homenet environment.   The specific functionality that I want is the same functionality you get with infrastructure wifi in a large office environment: that my laptop continues to work as I switch from AP to AP, without renumbering.   I don't think your mesh environment achieves that.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 24 Jun 2013 13:45:56 +0200

> The routing mesh you're describing sounds like it would work, and be
> quite useful, but not for a homenet environment.

Why so?

> The specific functionality that I want is the same functionality you
> get with infrastructure wifi in a large office environment: that my
> laptop continues to work as I switch from AP to AP, without
> renumbering.

> I don't think your mesh environment achieves that.

It certainly did last week.  (I'm not in Paris right now, and I cannot
check if it still does.)

-- Juliusz

---

From: Ray Hunter <[email-masked]>
Date: Mon, 24 Jun 2013 14:12:23 +0200

> It certainly did last week.  (I'm not in Paris right now, and I cannot
Juliusz: I think Ted means, "without installing new (mesh knowledgable)
code on my existing office device and have it participate in the routing
protocol."

Ted: working with AP's like the "infrastructure wifi in a large office
environment" today implies a common bridged connection between all AP's
advertising a single SSID and a common radio technology AFAIK.

Don't hesitate to correct me if I'm wrong.
 
May I suggest we make a summary table of all of the options on the
table, together with pros, cons and assumptions behind each?

I can think of at least 6 ways of approaching the desired result: none
of which is perfect assuming a starting point of today's devices "out of
the shrink wrap".

So that suggests to me it's an important topic for Homenet to at least
explicitly document as a gap.

regards,
RayH

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Jun 2013 09:26:21 -0400

> Don't hesitate to correct me if I'm wrong.

Yes, you are correct.  And handoff between APs.

I think that it's unobtainable in the home(net) at this time, and I think that
it is out-of-scope for homenet.

By this, I mean that I think that application of suitable specifications by
AP vendors could make it happen without putting specific requirements on
homenet.  I think that the APs might have to do things like figure out how to
do their wire-side coordination over IP(v6).

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Jun 2013 09:48:47 -0400

> It certainly did last week.  (I'm not in Paris right now, and I cannot

Okay, then maybe I just don't understand the architecture.   You are saying that it's a routed architecture, but in order for what I am describing to work, you need either bridging between wired and wireless, which is undesirable in the homenet architecture, or else you need some kind of layer two tunnel mesh connecting the wireless links, using the wired link as a transport for the tunnels.

Based on what you are saying, it must be the case that you are doing something like the latter, or else something like the former, but I don't know your architecture, so I can't tell which.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Jun 2013 09:53:56 -0400

> code on my existing office device and have it participate in the routing

Yeah, clearly that is out of scope for homenet, but I think Juliusz isn't asking us to do that, so it's okay.

> advertising a single SSID and a common radio technology AFAIK.

That seems likely.   Although if most of the communication is wireless-to-wire, the common radio technology bit isn't as important, as long as it's a common family—e.g., 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac.   But we don't know what most of the communication will be, so that's questionable.

> explicitly document as a gap.

Yup.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Jun 2013 10:00:40 -0400

> do their wire-side coordination over IP(v6).

This is a good point.   I think documenting it as a gap is the way to go—I agree that there's probably no way to make the right thing happen automatically, since "the right thing" is situationally variable.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 24 Jun 2013 16:16:59 +0200

> Okay, then maybe I just don't understand the architecture.

As Ray rightly noted, our mobile nodes are participating in the
routing protocol (but not necessarily in routing -- they're just
announcing a /128 to their own address).  No renumbering happens when
such a node roams.

Once again: normal (RA) and mobile (AHCP+Babel) nodes can share the
same link, but the normal nodes need to renumber (and hence lose all
TCP sessions) when they switch links.  If you prefer, your network can
evolve: you can use unmodified ("homenet-compatible") nodes on the
homenet, but using modified ("homenet-aware") nodes you get extra
functionality.

I'll stress once again that this is not some paper protocol, this is
stuff that we have been running daily for years, and is used to access
the Internet for a number of grad students in our lab.  (Unlike the
official wifi, our mesh has good coverage of the couch in the grad
students' coffee room.)

(In practice, we're not running both RA and Babel on the same link; we
prefer to set up multiple interfaces on the same physical radio, some
of which run Babel and some of which run DHCPv4 and RA, due to
NAT-related issues.  In a pure IPv6 network, we'd probably be using
a single interface.)

This is why I'm hoping that the homenet architecture we converge on
has the following properties:

 - it uses layer-3 routing;
 - the choice of routing protocol isn't wired too deep within the
   architecture (for example, configuration information is not carried
   by the routing protocol, which is bad engineering in any case);
 - the choice of routing protocol is not constrained too much by the
   architecture.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Jun 2013 10:41:49 -0400

> homenet, but using modified ("homenet-aware") nodes you get extra

I don't think this is the right direction to go.   Requiring some kind of mobility stack on the host isn't something that I can see getting any significant market penetration in the general-purpose host environment.   It's fine for service provider environments where the service provider has some leverage to make special requirements on the host, and it's fine for environments like public metropolitan wireless where there's a strong incentive for adventurous people to install the software, but the homenet environment isn't that.

---

From: Jim Gettys <[email-masked]>
Date: Mon, 24 Jun 2013 11:11:27 -0400

On Mon, Jun 24, 2013 at 10:41 AM, Ted Lemon <[email-masked]> wrote:

> I don't think this is the right direction to go.   Requiring some kind of
> mobility stack on the host isn't something that I can see getting any
> significant market penetration in the general-purpose host environment.
> It's fine for service provider environments where the service provider has
> some leverage to make special requirements on the host, and it's fine for
> environments like public metropolitan wireless where there's a strong
> incentive for adventurous people to install the software, but the homenet
> environment isn't that.
>

Ted,

Right now, we have a  much bigger problem getting shipment of updated
routers with anything that homenet may recommend at all; getting code on
host operating systems is easier to do than getting router support
deployed.  I wish this weren't true, but it is.  If we aren't being
slightly optimistic, what are we doing spending our time on this mailing
list?

So if an approach has real value (and doesn't require a lot of kernel
dependent changes to support; we ain't going to do IPv8!), by the time the
routers ship, we can arrange to have host support.

I must therefore disagree (given that Juliusz has running code which is not
kernel intrusive today).

Dismissing such options out of hand even before any analysis is done is
therefore a mistake.
                                    - Jim

---

From: Acee Lindem <[email-masked]>
Date: Mon, 24 Jun 2013 15:30:32 +0000

On Jun 24, 2013, at 11:11 AM, Jim Gettys wrote:

On Mon, Jun 24, 2013 at 10:41 AM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

Ted,

Right now, we have a  much bigger problem getting shipment of updated routers with anything that homenet may recommend at all; getting code on host operating systems is easier to do than getting router support deployed.  I wish this weren't true, but it is.  If we aren't being slightly optimistic, what are we doing spending our time on this mailing list?

Jim - I'm not going to debate with you what is harder ;^) However, a requirement from the start of the Homenet WG is that we minimize changes to host software with the goal being none.

Thanks,
Acee

So if an approach has real value (and doesn't require a lot of kernel dependent changes to support; we ain't going to do IPv8!), by the time the routers ship, we can arrange to have host support.

I must therefore disagree (given that Juliusz has running code which is not kernel intrusive today).

Dismissing such options out of hand even before any analysis is done is therefore a mistake.
                                    - Jim

---

From: Jim Gettys <[email-masked]>
Date: Mon, 24 Jun 2013 11:40:27 -0400

On Mon, Jun 24, 2013 at 11:30 AM, Acee Lindem <[email-masked]>wrote:

>>  I don't think this is the right direction to go.   Requiring some kind
>> of mobility stack on the host isn't something that I can see getting any
>  Jim - I'm not going to debate with you what is harder ;^) However, a
> requirement from the start of the Homenet WG is that we minimize changes to
> host software with the goal being none.
>

> Acee

As I currently run a small mesh (of two nodes) in my house, using Juliusz's
babel protocol, and have not bothered to install the daemon that would be
required for me to roam between them (ahcpd, IIRC), I will note that in
practice, in a real home network, no upgrade is *required*.  The web's
abuse of TCP has assured most people won't notice.

That it would be better if I bothered to install the code, I do not doubt.

                                       - Jim

---

From: Teco Boot <[email-masked]>
Date: Mon, 24 Jun 2013 22:51:52 +0200

If TRILL isn't big enough, we can always take a look at Capwap [RFC5415].

Teco

---

From: Dave Taht <[email-masked]>
Date: Mon, 24 Jun 2013 14:23:38 -0700

> If TRILL isn't big enough, we can always take a look at Capwap [RFC5415].

I thought that capwap and its predecessor had some potential, I'm
sorry to see it not widely implemented.

For a longer view as to where in-home wireless may go take a look at
802.11ad, which among other problems uses a frequency range that
cannot go through walls, and falls back to older protocols to do so.

http://en.wikipedia.org/wiki/IEEE_802.11ad

I have no idea how the IEEE intends to solve the problems raised here
on homenet, been too busy trying to fix 802.11n.

-- 
Dave Täht

---

From: Henning Rogge <[email-masked]>
Date: Tue, 25 Jun 2013 07:52:51 +0200

> cannot go through walls, and falls back to older protocols to do so.

You mean falling back to a lower frequency band?

> on homenet, been too busy trying to fix 802.11n.

I think the low range of 60 GHz radio links can be a great feature,
because they limit the collision domain to a single room.

Henning Rogge

---

From: Mark Townsley <[email-masked]>
Date: Tue, 25 Jun 2013 11:26:04 +0200

> sorry to see it not widely implemented.

capwap and lwapp are both widely deployed in enterprise wifi installations. There is nothing stopping a home networking provider from selling this today, though it does involve L2-tunneling of all traffic from each AP back to a central node.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Tue, 25 Jun 2013 11:34:57 +0200

> Jim - I'm not going to debate with you what is harder ;^) However, a requirement from the start of the Homenet WG is that we minimize changes to host software with the goal being none. 

During one of the WG meetings, I remember agreement around what we deemed the "Thaler principle" - quite simply, that any solution phasing would be drawn along the line of whether or not it affected existing hosts. So, we *will* define a solution that doesn't affect hosts at all. But, if we absolutely must, we can identify generally useful extensions to the host stack. 

Zero host changes would be nice, but I don't think we're going to get away with that. Multihoming without NAT alone pushes us to the edges of existing IPv6 stack capabilities. 

- Mark

---

From: Teco Boot <[email-masked]>
Date: Tue, 25 Jun 2013 12:39:38 +0200

> capwap and lwapp are both widely deployed in enterprise wifi installations. There is nothing stopping a home networking provider from selling this today, though it does involve L2-tunneling of all…

I guess there is a reason not shipping capwap for homenets yet. Maybe costs, lack of plug&play, controller dependency, lack of open source code or simply unaware.

Just unboxed an Aironet 600 SOHO. This solves the office network problem: it provides VPN to office network with ethernet & WiFi access. I'll find out how home & guest networks are supported. Can such a WTP connect to multiple AC's? I don't let control my home & guest networks by others. So I need a mapping between SSID/LAN ports and my own AC. Or box the 600 :-)

Teco

PS: Read RFC 5415 before asking details. And I am not the capwap expert.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Jun 2013 12:49:12 -0400

> I guess there is a reason not shipping capwap for homenets yet. Maybe costs, lack of plug&play, controller dependency, lack of open source code or simply unaware.

capwap support was removed from the kernel in favor of vxlan support quite some time ago, apparently.   I don't know enough of the history to know why.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 27 Jun 2013 21:05:15 +0900

On Mon, Jun 24, 2013 at 8:56 AM, Juliusz Chroboczek <
[email-masked]> wrote:

> except for announcing its own /128

Its own? You don't mean to say that every device may only have one IP
address? That would be so... 1997.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Jun 2013 22:17:07 +0200

> Its own? You don't mean to say that every device may only have one
> IP address? That would be so... 1997.

I realise you're joking, but it's actually an interesting point you're
raising.  Should the interfaces of a mobile node be numbered?

One way, which is quite natural from a mesh networking point of view,
is to have an IP on the loopback interface and leave all interfaces
unnumbered.  This simplifies configuration and reduces routing
traffic, and actually improves compatibility with applications that
assume a single IP.

Another way is to use the same IP on all interfaces.  That's more or
less equivalent to the above, and is the Linux way of representing
unnumbered interfaces.

Then there's of course the possibility to put a distinct IP on each
interface.  It makes the networking specialists happy, but causes
a number of problems with applications that assume a single IP.

I guess it might be somewhat premature to discuss that particular
issue within the group, hence the OT marker.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Fri, 28 Jun 2013 07:50:40 +0200

> traffic, and actually improves compatibility with applications that

A "homenet-scope" or global IP on loopback and linklocal IPs on the
interfaces works fine and keeps the routing tables small. It also
makes it easier to compensate for linkloss. If we put a
"homenet-scope" IP on the interfaces a connection will break if the
interface with its destination IP goes down.

Henning Rogge

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 28 Jun 2013 15:01:20 +0900

> less equivalent to the above, and is the Linux way of representing

Not really. What about link-local addresses? What about privacy addresses?
What about seamless renumbering? What about multihoming via
source+destination based routing? All of those require support for multiple
IPv6 addresses on the same node.

I realize your main target is IPv4, and these things are not necessary in
IPv4, but the goal here is to design something whose primary target is
IPv6, so it must be designed with IPv6 in mind.

Of course, you can probably make the existing protocol support this by
simply tracking each address separately, but please think of the scaling
limitations that your design might encounter. If a node has too many
addresses, will you run out of packet space and be forced to drop the
"extra" addresses like kerberos does? Will you fragment routing packets?
Will the extra updates cause the system to become less efficient? Will a
host be able to DOS the system by simply acquiring too many IPv6 addresses?
And so on.

Remember: for the purposes of this working group, IPv4 is legacy and nice
to have. IPv6 is the design target.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 28 Jun 2013 15:32:18 +0200

> All of those require support for multiple IPv6 addresses on the same node.

Lorenzo, no modern protocol has any issues with a single node
announcing multiple host routes to itself.  That includes at least
OSPF, IS-IS, EIGRP, RIPv2, RIPng, EIGRP and Babel.  (You might run
into issues with RIPv1 and IGRP, which is a pity, since I rather like
IGRP.)

> I realize your main target is IPv4,

Please do not put words into my mouth.  My main goal is to develop
algorithms and protocols for networking, and show that they work in
practice.  Most of my work is independent of any practical protocol,
and could very well be applied to PUP if you felt so inclined.

It turns out that both Babel and AHCP were initially IPv6-only
protocols, and I only added IPv4 support when my users complained.
(That's the trouble with having users.)

> the goal here is to design something whose primary target is IPv6,
> so it must be designed with IPv6 in mind.

That's okay.  I've heard of that IPv6 thing before.

> please think of the scaling limitations that your design might encounter.

I don't know how to break it to you, Lorenzo, but the routing community
has given a little bit of thought to getting its algorithms to scale.

> If a node has too many addresses, will you run out of packet space
> and be forced to drop the "extra" addresses like kerberos does?

No.

> Will you fragment routing packets?

No.

> Will the extra updates cause the system to become less efficient?

Yes.  The effect is linear in distance vector, and O(n log n) in naive
link state.  It is possible to achieve linear scaling in link state if
you're smart.

We used to teach that in third year.  We do it in fourth year now.

> Will a host be able to DOS the system by simply acquiring too many
> IPv6 addresses?

Yes.  Acquiring a few million addresses should be enough to notice.

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Jun 2013 11:14:04 -0400

Acee Lindem <[email-masked]> wrote:
    ac> Jim - I'm not going to debate with you what is harder ;^) However, a
    ac> requirement from the start of the Homenet WG is that we minimize changes to
    ac> host software with the goal being none.

1) minimize != zero
2) Juliusz' code works for hosts with current hosts stack,
   they just wind up renumbering if they change access points.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 29 Jun 2013 00:29:19 +0900

> into issues with RIPv1 and IGRP, which is a pity, since I rather like

Then we have no problem, then. We'll expect each host to announce N routing
entries, one per address, and document things as such. I only asked the
question because you said "its address" instead of "its addresses", which
to me suggested you weren't thinking of multiple addresses. I assume the
implementation does this today, then?

> We used to teach that in third year.  We do it in fourth year now.

One of the things that are always very hard to understand in fourth year is
that often the performance of real-world designs (not to mention
implementations) is very far away from what is optimal.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 28 Jun 2013 22:13:33 +0200

>> no modern protocol has any issues with a single node announcing
>> multiple host routes to itself.

> We'll expect each host to announce N routing entries, one per
> address, and document things as such.
[...]
> I assume the implementation does this today, then?

The standalone babeld implementation does this by default.  The
implementation included in Quagga has defaults consistent with the
other routing protocols included in Quagga, and needs some
reconfiguration to behave as you desire.

Please have a look at

  http://babelweb.wifi.pps.univ-paris-diderot.fr:8080/

You'll see that the node with router-id

  e2:46:9a:ff:fe:4e:91:e2

has addresses

  2001:41d0:1:f19f:e246:9aff:fe4e:91e2
  192.168.4.40

which are both being redistributed as host routes (metric=96 from
ariane).  These happen to belong to different address families, but
I could simply add another IPv6 address to this node, and the routing
daemon would react within seconds and redistribute an additional host
route.  Please let me know if you want a demo, we'll try to do it in
real time.  (Isn't Babelweb cool?  Demonstrating routing protocls
across the Atlantic :-)

The important thing to realise is that none of the above is specific
to Babel -- Babel is just what I'm most competent with, so I tend to
use it for my demos.  Any good technician familiar with any of the
classless routing protocols I listed in my previous mail could do the
same with his favourite routing daemon.

(And in case you're wondering, while only Babel has Babelweb, the mesh
community have been developing some pretty cool network visualisation
software for the other mesh routing protocols; unfortunately, they are
not being advertised, and are rotting in confidential git repositories
somewhere in central Europe.  Folks, when you get ready to market your
first Homenet router, speak to us -- both your users and your bosses
will love pretty pictures that update in real time.)

-- Juliusz