Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt

From: Ray Bellis <[email-masked]>
Date: Tue, 3 Jan 2012 13:40:56 +0000

On 29 Dec 2011, at 22:33, Howard, Lee wrote:

> I got tired of waiting for someone else to drive consensus on a routing solution

If there is consensus, it's for zOSPF, if only because no-one else appears to believe strongly enough in their preferred solution to write a draft about it.

I think Mark and I will need to make that call quite soon, but probably not until the authors of the architecture draft have incorporated the routing requirements and other comments since Taipei and put those into -01.

> I hope folks find this useful.[2]

Thanks Lee, that does indeed look useful.

Ray

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 13 Jan 2012 11:49:24 -0500

> -----Original Message-----
> From: Ray Bellis [mailto:[email-masked]]
> Sent: Tuesday, January 03, 2012 8:41 AM
> To: Howard, Lee
> Cc: [email-masked]
> Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-
> comparison-00.txt
>
>
> If there is consensus, it's for zOSPF, if only because no-one else appears to believe strongly
> enough in their preferred solution to write a draft about it.

I don't think there's consensus on zOSPF.  I think there are a few strong advocates and a lot of pointed silence I did present an alternative (based on a draft), which had an equal mix of "interesting" and "bleah."

The problem with zOSPF is that it doesn't meet our requirements.  It doesn't detect borders (unless the border happens to have another zOSPF router with the wrong password), it requires configuration (for the password), it doesn't handle walled gardens (a requirement being debated), it's not lightweight.

I'm trying to be fair, and not just protect the PIO proposal because I proposed it.  It needs work.  Its biggest lack is the need for hierarchical addressing, but I think draft-baker-homenet-prefix-assignment solves that.  I don't want to see zOSPF adopted just because its advocates were louder.

> I think Mark and I will need to make that call quite soon, but probably not until the authors
> of the architecture draft have incorporated the routing requirements and other comments
> since Taipei and put those into -01.

My perception is that we have three people in favor of zOSPF, three supporting a PIO, seven each supporting a different alternative, and 30 silent.

Lee

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: Don Sturek <[email-masked]>
Date: Fri, 13 Jan 2012 09:13:45 -0800

As one of the "silent" ones in Lee's note, I agree with what he is saying.

While homenet needs to define a home routing solution, the following are
the requirements for that solution from my perspective:
1)  Must be an established, existing, deployed routing protocol (or
heavily based on one).  We cannot afford to go through the process of
defining something new in homenet......
2)  Must be lightweight.   Unfortunately, I don't see a lot of Wi-Fi (or
other current home networking) router vendors in the group (or chipset
manufacturers for these solutions) but there is not a lot of spare
flash/RAM in many devices to support a large footprint solution.  It might
even be worth reaching out to some of these folks to get their opinions if
they aren't participating in homenet.....
3)  Must be auto configurable.     For nearly all device deployments (eg,
smart energy, video/audio distribution), it cannot take professional IT to
install, configure or update home routing networks.  Also, many devices
will be "headless" in that they cannot support user input.  Even having a
third device like a smart phone, tablet, etc. to configure a headless
device onto a home network requires software, documentation, etc.  If it
requires support then there is probably a major question whether it would
be deployed by manufacturers.

Hopefully the routing solution we choose meets the criteria above.......

Don

On 1/13/12 8:49 AM, "Howard, Lee" <[email-masked]> wrote:

>I don't think there's consensus on zOSPF.  I think there are a few strong
>advocates and a lot of pointed silence I did present an alternative
>(based on a draft), which had an equal mix of "interesting" and "bleah."
>
>The problem with zOSPF is that it doesn't meet our requirements.  It
>doesn't detect borders (unless the border happens to have another zOSPF
>router with the wrong password), it requires configuration (for the
>password), it doesn't handle walled gardens (a requirement being
>debated), it's not lightweight.
>
>I'm trying to be fair, and not just protect the PIO proposal because I
>proposed it.  It needs work.  Its biggest lack is the need for
>hierarchical addressing, but I think
>draft-baker-homenet-prefix-assignment solves that.  I don't want to see
>zOSPF adopted just because its advocates were louder.
>
>My perception is that we have three people in favor of zOSPF, three
>supporting a PIO, seven each supporting a different alternative, and 30
>silent.
>
>Lee
>
>
>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.
>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: Acee Lindem <[email-masked]>
Date: Fri, 13 Jan 2012 12:38:52 -0500

Hi Lee,

See inline. 

> I don't think there's consensus on zOSPF.  I think there are a few strong advocates and a lot of pointed silence I did present an alternative (based on a draft), which had an equal mix of "interest…

First let's quit calling it zOSPF. It is OSPFv3 with auto-configuration. 

> 
> The problem with zOSPF is that it doesn't meet our requirements.  It doesn't detect borders (unless the border happens to have another zOSPF router with the wrong password),

While this should be part of the solution, I don't see this as something that it necessarily should be built into the routing protocol. 

> it requires configuration (for the password),

How does any protocol do authentication w/o a shared key? If you don't do authentication, you don't need a key. 

> it doesn't handle walled gardens (a requirement being debated),

I don't fully understand this requirement and how it would be handled w/o configuration. 

> it's not lightweight.

A commercial router implementation supporting all the features including OSPF TE and VPNs is certainly not lightweight. However, I just downloaded the latest quagga suite and it is only about 21K there. 

Acee-Lindems-iMac-2:ospf6d ealflin$ wc -l  *.[c.h] 
     875 ospf6_abr.c
      78 ospf6_abr.h
     787 ospf6_area.c
     129 ospf6_area.h
    1270 ospf6_asbr.c
      95 ospf6_asbr.h
    1027 ospf6_flood.c
      66 ospf6_flood.h
    1654 ospf6_interface.c
     154 ospf6_interface.h
    1578 ospf6_intra.c
     220 ospf6_intra.h
    1019 ospf6_lsa.c
     254 ospf6_lsa.h
     582 ospf6_lsdb.c
      98 ospf6_lsdb.h
     348 ospf6_main.c
    2548 ospf6_message.c
     149 ospf6_message.h
     945 ospf6_neighbor.c
     137 ospf6_neighbor.h
     322 ospf6_network.c
      50 ospf6_network.h
      85 ospf6_proto.c
     122 ospf6_proto.h
    1409 ospf6_route.c
     305 ospf6_route.h
     535 ospf6_snmp.c
      29 ospf6_snmp.h
     701 ospf6_spf.c
      94 ospf6_spf.h
     707 ospf6_top.c
      78 ospf6_top.h
     697 ospf6_zebra.c
      51 ospf6_zebra.h
    1892 ospf6d.c
     125 ospf6d.h
   21215 total

I'm not sure about commercial deployments, but I know this distribution has been used as the basis for network research. 

Thanks,
Acee

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Jan 2012 15:40:51 -0500

>>>>> "Acee" == Acee Lindem <[email-masked]> writes:
    >> The problem with zOSPF is that it doesn't meet our requirements.
    >> It doesn't detect borders (unless the border happens to have
    >> another zOSPF router with the wrong password),

    Acee> While this should be part of the solution, I don't see this as
    Acee> something that it necessarily should be built into the routing
    Acee> protocol.

    >> it requires configuration (for the password),

    Acee> How does any protocol do authentication w/o a shared key? If
    Acee> you don't do authentication, you don't need a key.

Yes, this is a general problem, which is why I keep asking what are our
real requirements here.

    >> it doesn't handle walled gardens (a requirement being debated),

    Acee> I don't fully understand this requirement and how it would be
    Acee> handled w/o configuration.

I don't understand this criticism.  Why are walled gardens different
than multiple ISPs?

    >> it's not lightweight.

    Acee> A commercial router implementation supporting all the features
    Acee> including OSPF TE and VPNs is certainly not
    Acee> lightweight. However, I just downloaded the latest quagga
    Acee> suite and it is only about 21K there.

rtr3-[/usr/pkg/sbin] mcr 10007 %size ospf6d /usr/pkg/lib/libzebra.so.0
   text    data     bss     dec     hex filename
 221476   11328    3132  235936   399a0 ospf6d
 272449   23848    3120  299417   49199 /usr/pkg/lib/libzebra.so.0

No all of libzebra might really be used.  So 11K code, plus up to 23K.
I think that half of the code can be ripped out (and I wish I had time
to do).

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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 13 Jan 2012 16:03:49 -0500

Hi Michael,
Can you provided a precise definition of "walled garden", as well as, define the bi-directional connectivity rules with a few bullets (hopefully less than 5). 
I fear there may be more than one view of this (or possibly I'm the only one ;^). 

Thanks,
Acee

---

From: Ray Hunter <[email-masked]>
Date: Fri, 13 Jan 2012 22:03:55 +0100

How would PIO cope with marginal / ad hoc L2 wireless associations that 
can come and go depending on local radio conditions?
[A can always see B, B can always see C, but A can only sometimes see C]

Unless we're assuming all Homenet inter-router links are wired (which is 
certainly not the case in my house)

AFAIK OSPFv3 has better support for routing over ad hoc wireless links 
if necessary (MANET).

I believe most "traditional" routing protocols cannot cope well with 
this challenge.
e.g IS-IS could fail to elect a Designated Intermediate System visible 
to all nodes.

regards,
RayH

---

From: Ole Troan <[email-masked]>
Date: Fri, 13 Jan 2012 23:38:52 +0100

> I fear there may be more than one view of this (or possibly I'm the only one ;^). 

I presume we are talking about multi-homing to non-congruent topologies.
as described here http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03

not sure what exact problems with walled gardens would affect routing though. 

cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Jan 2012 14:32:12 -0500

>>>>> "Acee" == Acee Lindem <[email-masked]> writes:
    Acee> Hi Michael, Can you provided a precise definition of "walled
    Acee> garden", as well as, define the bi-directional connectivity
    Acee> rules with a few bullets (hopefully less than 5). I fear there
    Acee> may be more than one view of this (or possibly I'm the only
    Acee> one ;^).

I don't have a precise definition.
This is what I would advance:

  + A walled-garden network is provided by a service-specific internet
    service provider (SS/ISP) to a residential or small office.  
  + The service-specific connection is in the form of a dedicated WAN link into
    the dwelling. (The link may be physical or might be carried by a virtual
    layer-2).  Some dwellings may have only the service specific connection.
  + The service-specific connection provides access to a service
    (IPTV is a known example), and is not general Internet service.
  + The IPv6 service is reachable only using IPv6 from a block that the
    service-specific ISP will allocate to the residence using regular
    mechanism.  
  + The IPv6 service is numbered using globally unique IPv6 addresses,
    which are usually not accessible outside of the "garden", i.e. they
    are not routed in the global Default-Free Zone.
  + In IPv6, no special DNS tricks are required to make the clients
    systems pick the right target address.  Multiple AAAA records, 
    (possibly with walled-garden ACLs on authoritative servers) and
    happy eyeballs is enough.

A walled-garden is no different than a multiple ISPs in a residence,
except that general internet traffic does not transit that connection.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Jan 2012 15:54:29 +0200

Lee,

> The problem with zOSPF is that it doesn't meet our requirements. It doesn't detect borders (unless the border happens to have another zOSPF router with the wrong password), 

The problem is that we have incomplete proposals, and people are making evaluations based on assumptions on what those incomplete specification or implementation parts might be. We also have a _system_, not an individual protocol, and several protocol implementation modules need to co-operate so that the system delivers the desired behavior. For instance, if we think about the home network as a black box, it needs to talk to external world probably at least with DHCP and DHCP-PD, talk to hosts within the network with ND, do something for naming and discovery protocols, etc. Internally, it may do something black box magic for the routing and other things, of course.

A case in point. I'm working on an implementation that most definitely detects borders, and still uses OSPF autoconfiguration to handle routing. How does it detect borders? It attempts to do DHCP, DHCP-PD, OSPF autoconfiguration, and the usual "I have a working connection to the Internet" probing techniques. It also allows for manual configuration, or the "this port is for Internet, the other one is for internal network" models.

> it requires configuration (for the password),

Acee's autoconfiguration design is nice in that it can be guaranteed to not accidentally connect to enterprise and ISP networks simply due to the selection of the area and instance IDs. See Section 2 in draft-acee.

I think it would be useful to provide an automatic security model on top of the autoconfiguration design, and some ideas for that have been circulated on the list. But I would think that the security model and issues in setting it up are very similar between different routing protocol-based designs and with the PIO design. For instance, we can provide ssh-like security relatively easily, but if you want to go beyond that then you must have configuration.

> it doesn't handle walled gardens (a requirement being debated), it's not lightweight. 

I agree that link state routing protocols are a bigger amount of code than, say, RIP. But I think the crux is code availability and reliability, rather than pure measurement of lines of code. Most home network vendors would use an openly available implementation rather than write their own, so having one available is more important than the number of lines in it. I think I have seen the working group favor support for complex topologies, preventing user action from leading to non-working network more than for absolutely simplicity. I think for absolute simplicity and code availability, RIP could be our choice.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Jan 2012 16:19:42 +0200

Many thanks for writing the draft(s)!

> In particular, I have no knowledge of MANEMO or RPL, so I can't evaluate them. MANEMO probably shouldn't be here, since there isn't even a draft to point to. 

I think you can delete the MANEMO part. MANEMO was loose collection of ideas roughly in the same direction as your PIO proposal.

For RPL, IS-IS, etc. you'll find that you have to come up with some additional ideas on how the other aspects of the home network are handled, not just the pure routing part. (For this reason, it might actually be useful to break down the analysis a bit. For the pure routing part, PIO-RIP-OSPFAC differ in such and such ways. The mechanisms for border detection are A-B-C and they differ in these other ways. Etc.)

Jari

---

From: Ray Hunter <[email-masked]>
Date: Sat, 21 Jan 2012 13:23:34 +0100

What is wrong with applying the Autonomous System concept to Homenet (as 
defined in RFC1930)?

IMVHO a number of problems might become clearer if Homenet explicitly 
acknowledged management boundaries and potential conflicts in routing 
policy.

Under RFC1930: Homenet would be classified as a multi-homed site.

A "Walled Garden" would then be when a Homenet AS has a private peering 
with a non-transit AS.

On the upside, there's also a number of private AS numbers reserved for 
use if needed.

Interestingly enough, applying the AS model also highlights a potential 
downside weakness in the current RFC6204 & 6204bis documents (which seem 
to assume that the customer's site is an integral part of a single 
provider's AS, and not an independent entity with its own routing 
policy), and PD & DHCPv6 (the protocol does not contain an AS number, 
and a Homenet may communicate with multiple non-coordinated sources of 
management information).

BTW I am not explicitly advocating BGP.

regards,
RayH

Michael Richardson wrote:
>>>>>> "Acee" == Acee Lindem<[email-masked]>  writes:
>>>>>>