Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 1 Aug 2011 10:33:28 -0500

> In a routed home network, you want guest networks and non-guest
networks to be
> routed, but not talk to each other. Carrying in the IGP the
information about
> whether each /64 assigned to an interface is for a guest network or a
non-
> guest network allows the routers to apply the appropriate firewalls
between
> the guest network and the non-guest network, while still routing both
guest

Agreed to the use case, but having to run a heavy-duty protocol like
OSPF or ISIS is an overkill to this use case, IMO.

However, having the firewall to pick up the policy from IGP database is
something pretty advanced, IMO.

> and non-guest prefixes. It's a bit like having two VRFs or an MPLS
VPN.

I like the analogy, of course, MPLS VPN can be made to have two L3VPNs
talk to each other. :-)). MPLS VPN can not replace firewall function. I
am sure you didn't mean that either, but just in case.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Lorenzo Colitti
> Sent: Saturday, July 30, 2011 2:42 PM
> To: Brzozowski, John
> Cc: [email-masked]
> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router
> 
> On Sat, Jul 30, 2011 at 00:34, Brzozowski, John
> <[email-masked]> wrote:
> 
> 
> 	>* can distribute information beyond IP reachability; for
example, "this
> 	>prefix belongs to a guest network" or "this is a prefix that I
have
> 	>tentatively assigned to my interface, not a prefix that is
already in
> 	>use". This would be useful for autoconfiguration.
> 
> 	[jjmb] as I emailed before why would this be required of the LAN
side
> 	network is part of an already delegated prefix?  Am I missing
something?
> 
> 
> 
> In a routed home network, you want guest networks and non-guest
networks to be
> routed, but not talk to each other. Carrying in the IGP the
information about
> whether each /64 assigned to an interface is for a guest network or a
non-
> guest network allows the routers to apply the appropriate firewalls
between
> the guest network and the non-guest network, while still routing both
guest
> and non-guest prefixes. It's a bit like having two VRFs or an MPLS
VPN.
> 
> As regards the "tentative" tag, that might be useful when doing
> autoconfiguration. As Ole says, a CE could pick one random /64 out of
the
> aggregate for each of its interfaces and do collision detection to see
if it's
> unique. If the IGP carries a flag saying "this prefix is tentative"
that might
> make it easier.
> 
> Of course, these are just examples of why a protocol that can carry
additional
> information beyond just "this prefix lives here with this metric" can
be
> useful: it allows the network to do stuff that we haven't thought of
yet.
> Cheers,
> Lorenzo

---

From: "Lee Howard" <[email-masked]>
Date: Mon, 1 Aug 2011 13:22:45 -0400

Is anyone capturing this thread into a problem statement/requirements document, or are we 
going to design new protocols, and then fight about which one meets the requirements?

Can we take this to Homenet mailing list?

Lee

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Kline
> Sent: Sunday, July 31, 2011 6:10 AM
> To: Satoru Matsushima
> Cc: [email-masked]
> On 31 July 2011 09:08, Satoru Matsushima <[email-masked]> wrote:
> > On 2011/07/31, at 17:39, Erik Kline wrote:
> >
> >>> additional information beyond just "this prefix lives here with this metric"
> >>> can be useful: it allows the network to do stuff that we haven't thought of
> >>> yet.
> >>
> >> Like advertise future standardized "this *service* is reachable via
> >> this path" sorts of things.  The routing protocol could aid in service
> >> discovery this way.
> >
> > I think it would be a good point.
> > A crazy idea come up me like opaque-lsa for advertise beyond advertising just prefix, and
> a flavor of bgp community to import/export to manage connectivity among routing
> instances.
> 
> Hehe.  On the plane ride back I was thinking of something like ES-IS
> advertising service things to IS-IS routers, which could choose to
> propagate them.
> 
> Of course, I also though to redo IS-IS without OSI numbering and just
> use link-local addresses...somehow.
> 
> =)
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 2 Aug 2011 21:34:59 +0000

+1 for the below.

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 2 Aug 2011 21:49:25 +0000

I was thinking the same thing, the thread is going so well here. :)

=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

On 8/1/11 1:22 PM, "Lee Howard" <[email-masked]> wrote:

>>Of Erik Kline

---

From: Mark Smith <[email-masked]>
Date: Wed, 3 Aug 2011 18:37:29 +0930

On Tue, 2 Aug 2011 21:34:59 +0000

> +1 for the below.

Do people realise that ISIS was designed in the era of 20Mhz Motorola
68000s, and that Cisco used to have a paper which advised that an OSPF
area should had no more than 50 routers and 200 links, and they were
talking about Cisco 2500s, which IIRC had Motorola 68020s and no more
than 512KB or 1MB of RAM? 

The cheapest residential CPE today and in the last 5 years easily
exceeded the processing power of the routers when ISIS and OSPF were
developed. My 4 year old ADSL router has a 200Mhz ARM CPU in it and
16MB of RAM, and it was a baseline model, costing less than $80 - $100
US (i.e. around $100AU). 

OSPF and ISIS are not heavy duty or heavy weight these days (and
haven't been for more than a decade), and provide distinct
re-convergence advantages over RIP, as well as the ability to carry
around or be easily extended to carry around information that is not
packet forwarding related e.g. services.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 3 Aug 2011 11:21:55 +0200

Hi Mark,

> packet forwarding related e.g. services.

I fully agree. I have MikroTik routers here that do RIP, OSPF, BGP, MPLS etc. on both IPv4 and IPv6 in a box costing $40.

Sincerely,
Sander Steffann

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 03 Aug 2011 11:20:01 +0100

> packet forwarding related e.g. services.

On a similar note, I'd like to propose that all new vespa scooters be
equipped with turbo and superchargers, power steering, electronic drive
control, dolby 5.1 speakers and tow-hitches.  The rationale is quite clear:
these technologies are mature, not at all heavy duty, and carry distinct
advantages over alternatives, as well as providing the ability to carry
around or be easily extended to carry around equipment that is not scooter
related e.g. building materials, boats, rock-concert kit, etc.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Wed, 03 Aug 2011 12:32:01 +0200

>related e.g. building materials, boats, rock-concert kit, etc.

I don't think this remark doesn't help in the context of homenet. What's the
point of now saying, oh OSPF, IS-IS, are way too big, it has to be RIP. Only
to later find out that you may need all kinds of extra protocols for things
that are already solved in OSPF, etc.

I think the main thing that should be done now is trying to figure out the
scope of a homenet. How many kitchen sinks do we want.

---

From: [email-masked]
Date: Wed, 3 Aug 2011 13:34:49 +0300

I do not think its surprising that hardware can run these things. Sure it
can. The phone that I am using to write this message certainly can. My
watch propably could too.

Its also not surprising that with more/newer protocols you can handle more
situations, >15 hops, pathologic topologies, user errors,
multihoming,mobility, qos.

I have no skin in this game, but I am still from the school of thought
that it matters what code is easiest available, is already in peoples
devices, and is so simple that a home router sweat shop can get it right
without employing an actual engineer.

Jari

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 03 Aug 2011 12:02:18 +0100

> scope of a homenet. How many kitchen sinks do we want.

We need simplicity.  A specification like this is going to be a baseline
spec, and shouldn't contain many bells and whistles.

Don't get me wrong.  I like technology as much as anyone else, and the
thought of recommending RIP over ISIS for anything makes me feel dirty.
But the point is, RIP is a very simple protocol to implement, unlike either
IS-IS or OSPF.  If you create a standard which sets the baseline too high,
you will end up with trashy implementations and excess complication.  More
importantly, if you specify too much in an early RFC, how do you remove it
later if it turns out that it was a bad idea in retrospect?  Look at all
the trouble that 6to4 is causing, yet people on this mailing list are
shirking at deprecating it.

Yes, you _can_ get boxes which do everything, like the Mikrotik boxes.  But
how many end-users are going to end up configuring mpls on their home
networks, or setting up iBGP on their multi-router installations?  There is
no need for this level of complexity.  It will confuse for no good purpose.
 Remember, we are specifying something for Mom, Granddad and uncle Joe, to
be implemented by Belkin.  We're not specifying something for Nick, Philip
and Sander, to be implemented by Cisco or Juniper.

Perfection will be achieved not when there's nothing more to add, but when
there's nothing more that can be taken away.

Nick

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 3 Aug 2011 13:13:38 +0200 (CEST)

On Wed, 3 Aug 2011, Nick Hilliard wrote:

> IS-IS or OSPF.

Could someone give a pointer as to how much harder OSPF is to implement?

The only metric I can think of right now is size of code in Quagga, where 
the source code for their different components are as follows:

component	size
ripd 		308k
ripngd		224k
ospf6d		613k
ospfd		1469k
bgpd		1652k
isisd		665k

I don't know what exactly this measures, saying isis is twice the code 
compared to rip (if ripd and ripngd can be considered two separate 
components, otherwise it's almost the same).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Sander Steffann <[email-masked]>
Date: Wed, 3 Aug 2011 13:20:35 +0200

Hi Nick,

> no need for this level of complexity.  It will confuse for no good purpose.

That is not what I was saying (or at least not what I meant to say). I just wanted to show that it's possible to implement these protocols on cheap hardware. I fully agree that we must design something fool-proof and easy to use for the average home user. I just don't agree that we should limit ourselves to protocols like RIP for hardware reasons.

> there's nothing more that can be taken away.

True, but let's not take away options for the wrong reasons.
- Sander

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 03 Aug 2011 13:34:37 +0100

> the source code for their different components are as follows:

BIRD tells a similar story in terms of kchars:

rip:  39k
ospf: 286k
bgp   158k

XORP also shows similar discrepancies in length, although it being what it
is, the numbers are about 10x any other implementation.

And the RFC for OSPFv2 is 243 pages, vs. 38 for RIP.

Look, I'm not going to offer a formal proof that OSPF/ISIS are more
complicated, but I think it's fair to say that we all know they are?  And
by quite a substantial degree too?  And moving on from that, the question
which matters is whether they form an appropriate base-line spec for CPE
devices.  I would suggest not, and I'm going to leave it at that.

Nick

---

From: Mark Smith <[email-masked]>
Date: Wed, 3 Aug 2011 22:27:51 +0930

On Wed, 03 Aug 2011 12:02:18 +0100

> shirking at deprecating it.

You seem to be assuming that CPE code is implemented from scratch.
It's not, most commonly it is packaged up Linux with busybox, and, as an
example, for IPv6 RAs, radvd. Quagga or one of the other open source
OSPF implementations would easily run on CPE and is likely to be used.
OpenWRT would be a very good example of what common CPE hardware is
capable of with the right software, and quagga is a package available
for it.

> there's nothing more that can be taken away.

Yes, but if you take away essential or valuable functionality, you've
gone too far, and will have to put it back or use something else to
replace it.

A basic OSPF default configuration with a single backbone area, which
discovers any neighbors automatically on selected interfaces (i.e. all
CPE non-WAN interfaces), forms adjacencies with them and then trades
LSAs etc. is quite simple. Troubleshooting OSPF verses RIP is possibly a
bit harder, but then mums and dads aren't going to be capable of
troubleshooting RIP either.

Regards,
Mark.

---

From: [email-masked]
Date: Wed, 03 Aug 2011 15:32:16 +0200 (CEST)

> You seem to be assuming that CPE code is implemented from scratch.

As far as I know, that used to be the case for a lot of CPEs from
various Asian vendors and probably also others (e.g. Linksys).

> example, for IPv6 RAs, radvd.

I believe several vendors have changed their software development
model, and do indeed deliver systems based on Linux nowadays. I'd like
to see some more documentation before I conclude that this applies to
*most* vendors.

> Quagga or one of the other open source

This is where I'm not completely convinced. A CPE vendor may conclude
that it is cost effective to deliver a system based on a Linux kernel,
but that other resource constraints (memory, flash, etc) dictate a
different set of software for routing protocols. Yes, more memory or
flash could easily accomodate Quagga etc - but these vendors are in
the business of saving 10 cents here and 50 cents there - multiplied
by many CPEs.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Aug 2011 09:37:00 -0400

> BIRD tells a similar story in terms of kchars:

Why does it matter at all? All consumer-grade home routers are built on
open-source software. The implementation difficulty seems irrelevant to
me. They'll just take what's out there and integrate it to their kit.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Ray Bellis <[email-masked]>
Date: Wed, 3 Aug 2011 13:50:13 +0000

On 3 Aug 2011, at 14:37, Simon Perreault wrote:

> open-source software.

In my experience that's simply not true.

When testing 20+ routers for SSAC035 and RFC 5625 we found _barely any_ that were using recognisable OSS stacks for their implementations.

Admittedly that was two years ago, and Linux / busybox / dnsmasq is probably somewhat more popular now than then, but the variety of bugs we saw then was far too great to suggest any significant commonality in their code bases.

Ray

[reply-to set to Homenet]

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 03 Aug 2011 15:06:56 +0100

> capable of with the right software, and quagga is a package available

The Quagga OSPFv3 implementation is not very good, to the extent that I
would not use it in production.  It lacks a pile of functionality, and is
relatively easy to crash.  The Quagga IS-IS implementation (which is the
only open source IS-IS implementation as far as I can tell) has
substantially not been updated since it was written 10 years ago - and does
not support e.g. ipv6.

Also, as several people have pointed out, many ip stack implementations are
build from scratch, in-house.

> gone too far, and will have to put it back or use something else to

It is still a lot simpler to add functionality to a specification than to
remove it later.  Consequently, it is better to start with simpler
recommendations and to augment with retrospect, rather than to figure out
the best way to fit as many kitchen sinks in as possible.

> troubleshooting RIP either.

Configuration complexity is not the problem.  The problem is CPE device
build complexity.  Pennies matter for these boxes.

Nick

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 3 Aug 2011 12:42:55 -0500

Indeed, Nick.

And even when they are purchased from outside (off-the-shelf), the cost
varies depending on the protocol stack. 

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Nick
> Hilliard
> Sent: Wednesday, August 03, 2011 10:07 AM
> To: Mark Smith
> Cc: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Thu, 4 Aug 2011 07:29:40 +0930

> to see some more documentation before I conclude that this applies to

I've worked with 4 residential IPv6 vendors in the last 18 months, and
all of them had CPE that was based on Linux etc., including one of the
famous ones.

There are a few other datapoints. Firstly the supported hardware for
projects like OpenWRT, Tomato etc. that are Linux based. I think it is
likely that the CPE has been easily "opened up" because it ran Linux in
the first place.

The other give away are the open source licenses and
downloadable source code that the vendors must provide. An Internet
search for the vendor name and "gpl" will usually show up the website
of where you can see the licenses and download the source code - if
they're complying with them of course.

> the business of saving 10 cents here and 50 cents there - multiplied

I understand that. Vendors however can be willing to increase pay
those increases if necessary - one of the vendors I worked with
increased the flash in the platform I worked on with them to support
IPv6.

The disappointing thing, at least from my recent experience with radvd,
is that it seems that these vendors aren't very willing to contribute
back to the projects they use. There may be opportunities to save
memory and flash in these projects which would be cheaper to sponsor
than putting extra memory or flash in each CPE. For example, the radvd
binary between 1.7 to 1.8 shrunk significantly because of this simple
patch -

http://lists.litech.org/pipermail/radvd-devel-l/2011-May/000609.html

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Thu, 4 Aug 2011 07:39:39 +0930

On Wed, 3 Aug 2011 12:42:55 -0500

> varies depending on the protocol stack. 

If they're Linux based, then the vendor is buying Brooklyn bridge. IPv4
and IPv6 come free with Linux, as does the kernel itself, as long as
you comply with the licenses.

The tragedy in some respects is that there still seems to be a level of
"preciousness" in the firmware, rather than realising it is extremely
commodity. Consequently, you see things like the same bug in the
firmware from two vendors, and have to ask for it to be fixed twice.
You also see a vendor diligently make improvements to their firmware,
and then they move to a new version of firmware from their upstream
supplier, which doesn't have any of the improvements. The vendor then
looses six months or more of time to market because the
improvements didn't end up being pushed back up stream, and they have
to re-implement them.

If the vendors got together and put their resources into projects like
OpenWRT everybody would be better off. The places where the vendor
could value add would be the combinations of software and hardware
features and performance (e.g. dual WAN, 3g, GigEs LAN interfaces,
network printer support etc), and the experience of using the device
e.g. the web gui.

Regards,
Mark.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 3 Aug 2011 20:19:14 -0400

> Admittedly that was two years ago, and Linux / busybox / dnsmasq is probably somewhat more popular now than then, but the variety of bugs we saw then was far too great to suggest any significant co…

+1.

Also, the number of scary bugs (and unusable UIs and weirdly limited features) makes me really really afraid of how routing protocols will be implemented, especially anything link-stateish. 

W

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 4 Aug 2011 05:24:48 +0000

....and does not require a home user to be an actual engineer either?

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 4 Aug 2011 05:26:29 +0000

The below is a good point, agree.

---

From: Mark Smith <[email-masked]>
Date: Thu, 4 Aug 2011 19:00:02 +0930

On Thu, 4 Aug 2011 05:26:29 +0000

> The below is a good point, agree.

So it would seem the assertion from those apposed to OSPF is that Mom,
Granddad and uncle Joe are competent at configuring, operating and
troubleshooting IPv4/RIPv2 and IPv6/RIPng, but will not be capable of
learning how to configure, operate or troubleshoot OSPFv3 (and v2)?

I'm confident that the reality is that Mom, Granddad and uncle Joe
aren't and won't be competent at any of things things, won't care
about them and more importantly shouldn't have to care about them. The
decision as to what type of technology goes into the "Internet box" the
customer uses should only be our concern, not theirs. It should just
work and be robust against common failure modes. If OSPF can be made to
autoconfigure itself (i.e. discover and establish adjacencies with
neighbors, trade databases etc.) as easily as RIP can, which it can
very easily, be just as robust as RIP is, which it certainly is, and it
provides useful and worthwhile benefits over RIP (quicker
reconvergence, carry other information, has better metric ranges, etc.
etc.), then it should be used.