Subject: Re: [homenet] Single or Multiple Routing Protocols in Homenet

From: Pierre Pfister <[email-masked]>
Date: Sun, 1 Jun 2014 10:47:03 +0200

Hello,

I’m not going to argue about which routing protocol to use (Juliusz remark about GRE tunnel was interesting thought), but…

See how hard it is ?

Home routers vendors will have a bad enough time putting a single routing protocols in their routers, 
we can’t ask them to put two of them. Nevertheless, their is so much ideology beside that discussion…
We are going to choose one, and what if we change our minds in 10 or 20 years ? What if a new protocol
is created that fits way better homenet requirements ? Once vendors are cool with one routing protocol,
we might want to allow home networks to move to a new one, or even the next version of the previous one.

I think it doesn’t cost much (really) to allow flexibility.
- Someone that administrate all the routers in the home should be able to use a different routing protocol than the one that homenet chose.
- In the future, we should be able to move from one routing protocol to another without backward compatibility (And that might mean that transition routers will have to support two routing protocols until it becomes useless to support the previous one).

So even if most will agree that supporting multiple routing protocol is a madness in the general case. 
It’s not that hard to ’support it’ while requiring one single routing protocol as mandatory in home networks.
And whenever we want to move to another protocol, maybe in 20 years, it will allow transitioning softly.

Have a nice day,

Pierre

Le 31 mai 2014 à 23:48, Gert Doering <[email-masked]> a écrit :

> Hi,
> 
> On Sat, May 31, 2014 at 12:17:16PM -0700, Douglas Otis wrote:
>>>> On Sat, 31 May 2014, Gert Doering wrote:
>>>> 
>>>>> So I'd keep the list of supported protocols as small as possible - and 
>>>>> stick to IP protocols.  ISIS is great for ISP environments, but does not 
>>>>> nicely adapt to a unix environment where the kernel has no idea about 
>>>>> ISO/OSI protocols and you have to do everything via raw sockets.  Which 
>>>>> would be a fairly typical environment for a CPE router.
> [..]
>> 
>> I could be wrong, but I don't think that was the point. There are also layer 2 protocols to consider.
> 
> I quoted my original comment above.  This is the context we're talking
> about: protocols to be considered for routing inside the homenet.
> 
> In *homenet*.
> 
>> Expecting everything to be handled at IP transport layer 3 will confront extremely difficult security issues.
>> 
>> Testing using a modern printer/scanner illustrated a major problem when devices were not restricted to link-local.  Something like RBridge supporting PPP would provide a much safer foundation upon which to build. 
>> 
>> All networks must begin with layer 2 starting points.  Selective routing between Rbridges would allow an ability to share data between HDCP enforced multi-media display devices using link-local addresses.  There will be video cameras, baby monitors, HVAC/SCADA controls, printers and scanners offering media stick access, etc. These devices were never intended to directly interface with the Internet.  These devices MUST NOT be assigned routable IPv4 or IPv6 addresses.  Using mDNS proxy into DNS would be setting the stage for major security disasters.
> 
> While this is all true, I cannot see how this related to what I said
> above, and to the question of "is ISIS better suited as a link-state
> protocol to transport opaque LSAs than OSPFv3?" - because *both* do that
> job without "assigned routable IPv4 or IPv6 addresses" - ISIS talks over
> L2 (or potentially IPv6 link-local as was mentioned), OSPFv3 talks over 
> IPv6 link-local.
> 
> This thread wasn't about questioning the whole homenet architecture, but
> about a specific side aspect: would additional routing protocols be considered
> a plus.  And I say "no", out of general reasoning, and because I consider
> the particular protocol to be not very well suited for typical SoHo router
> implementations.
> 
> Gert Doering
>        -- NetMaster
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Gert Doering <[email-masked]>
Date: Sun, 1 Jun 2014 12:50:23 +0200

Hi,

On Sun, Jun 01, 2014 at 10:47:03AM +0200, Pierre Pfister wrote:
> It?s not that hard to ?support it? while requiring one single routing protocol as mandatory in home networks.

Having multiple routing protocols and select between them is already 
permitted by the current HNCP draft (for example).

The question was more whether "add ISIS today" would bring a benefit to
homenet, and I still maintain "no" - to the contrary, it is harmful - as
you said, we can be happy if CPE vendors get one protocol right.

Gert Doering
        -- NetMaster

---

From: Sander Steffann <[email-masked]>
Date: Sun, 1 Jun 2014 14:38:43 +0200

Hi,

> you said, we can be happy if CPE vendors get one protocol right.

+1

I personally don't really care about which protocol that should be (I have some preferences, but "getting one protocol right" outweighs all those preferences by a huge margin) as long as we design something that is easy enough for CPE vendors to implement correctly so that for the home user everything just works.

Needing to implement multiple protocols, having to negotiate with other devices which of those protocols to use, network flaps because a device was added to the network that doesn't support the protocol that the other devices agreed upon etc. don't help in this regard.

Please remember: the end goal is to create a situation for home users that just works and works reliably, not to design the most fancy and cool combination of protocols possible...

Cheers,
Sander

---

From: Tim Chown <[email-masked]>
Date: Sun, 1 Jun 2014 13:51:38 +0100

On 1 Jun 2014, at 13:38, Sander Steffann <[email-masked]> wrote:

> Please remember: the end goal is to create a situation for home users that just works and works reliably, not to design the most fancy and cool combination of protocols possible…

Just as a reminder, here is what we converged on at IETF89 for text in the homenet arch. The “zero or one” protocol message was clear. I don’t recall a clear answer on whether to pass config info via the routing protocol or a separate protocol, but as HNCP shapes up as a proposal I suspect the tradeoffs will become clearer towards an answer there.

  "At most one routing protocol should be in use at a given time in a
   given homenet.  In some simple topologies, no routing protocol may be
   needed.  If more than one routing protocol is supported by routers in
   a given homenet, then a mechanism is required to ensure that all
   routers in that homenet use the same protocol."

Tim

---

From: Sander Steffann <[email-masked]>
Date: Sun, 1 Jun 2014 14:58:46 +0200

Hi Tim,

>   routers in that homenet use the same protocol."

Sounds good, and I see the need for having the possibility to introduce a new routing protocol in the future so that we can evolve if/when necessary. However, having multiple routing protocols will be disruptive in some ways. When a homenet consists of devices that all support the new protocol then connecting an older device that doesn't support it will force the whole network to switch to the old protocol. While this may be unavoidable when designing HomenetNG, it is not something we should be causing today.

Cheers,
Sander

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 01 Jun 2014 15:07:08 +0200

> [...] IPv6, where routers communicate using link-local addresses.  For
> what it's worth, Babel is quite able to establish adjacencies before
> addressing is up as well as in pure IPv4 networks.

I've received a few questions about this by private mail, so please let me
lecture a little.  The chairs will let me know if that's too much of an
off-topic for this list.

Take a traditional single-stack routing protocol for IPv4, say RIPv2 or
OSPFv2:

  1. your neighbour database is indexed by (interface, IPv4) pairs;
  2. your routes' next hops are (interface, IPv4) pairs.

This means that you need to wait for an IPv4 address before you can do
anything.  You can work around that by putting a (site-local) static IPv4
on the loopback interface, but that involves some administrative overhead,
and hence is not applicable to Homenet.

Compare this with an IPv4 routing protocol that is layered directly above
802.2, say a pure IPv4 implementation of ISIS:

  1. your neighbour database is indexed by (interface, MAC) pairs;
  2. your routes' next hops are (interface, IPv4) pairs.

Since MAC addresses always exist, you can establish neighbour relationships
as soon as the interface is up -- no need to wait for global addresses to
be assigned.  If you're link state, you can start flooding as soon as the
adjacency is up, which is pretty cool.  However, since next hops are IPv4
addresses, you still cannot route until both you and your neighbour get
assigned addresses.

Now take the simple same single-stack protocol and port it to IPv6 (RIPng
or OSPFv3):

  1. your neighbour database is indexed by (interface, link-local IPv6);
  2. your routes' next hops are (interface, link-local IPv6) pairs.

If link-local IPv6 exist soon enough after the link is up, you get all of
the benefits of a stable neighbour identifier -- you establish adjacencies
and start flooding as soon as the interface is up and has a link-local
IPv6.  In addition, since your next hops exist, you can start routing as
soon as the interface is up -- a big win if the address distribution
protocol is slow or unreliable.  Finally, you don't need to do anything
special when you renumber, the next hops use stable identifiers.

Consider now a double-stack protocol running over IPv6, such as Babel:

  1. your neighbour database is indexed by (interface, link-local IPv6);
  2. your routes' next hops are (interface, link-local IPv6) or
     (interface, IPv4) pairs, depending on the address family.

Here, for IPv6 you're just like the previous case; for IPv4, you need an
address before you can route.  The effect is that a Babel router starts
routing IPv6 as soon as the interface is up, but needs to delay installing
IPv4 routes until both neighbouring interfaces have an IPv4 address.  In
effect, when the address configuration protocol has a hiccup, IPv6 routing
remains stable but IPv4 needs to reconverge.

In summary, by running your routing protocol over IPv6, you get the
advantages of the ISIS approach, but in addition you gain:

 (1) the ability to run over GRE tunnels and OpenVPN in "tun" mode;
 (2) much simpler implementation on Unix  -- no need to use raw sockets,
     just plain RFC 3493.

What you don't get is the conceptual elegance of proper layering.

-- Juliusz

---

From: "Leddy, John" <[email-masked]>
Date: Sun, 1 Jun 2014 13:18:17 +0000

Not going to weigh in on what IGP.

Following on bellow, it would be good to think about what we are looking
for from the IGP.
Link state, full topology view, sub-second convergence?
Or reachability? And stability.

Independent of the choice of IGP, we still have to configure it, or
recommend settings.

john

---

From: Ray Bellis <[email-masked]>
Date: Mon, 2 Jun 2014 09:59:40 +0000

On 1 Jun 2014, at 14:07, Juliusz Chroboczek <[email-masked]> wrote:

> The chairs will let me know if that's too much of an off-topic for this list.

Not at all, IMHO that was a very useful explanation.

Ray

---

From: Acee Lindem <[email-masked]>
Date: Mon, 2 Jun 2014 22:08:08 +0000

Note that OSPFv3 can also support advertisement of IPv4 prefixes - see RFC
5838. 

Thanks,
Acee 

-----Original Message-----
From: Juliusz Chroboczek <[email-masked]>
Date: Sunday, June 1, 2014 6:07 AM
To: "[email-masked]" <[email-masked]>
Subject: [homenet] Routing over IPv6 [was: Single or Multiple
Routing	Protocols...]

---

From: Ray Hunter <[email-masked]>
Date: Tue, 03 Jun 2014 09:55:03 +0200

Liubing (Leo) wrote:
> Hi all,
>
> We have an ISIS auto-configuration draft under developing in ISIS WG (draft-liu-isis-auto-conf). Since Homenet/SME networks are one of the main scenarios our draft targets at, and we already have an OSPF-autoconf mechanism available (draft-ietf-ospf-ospfv3-autoconfig), during the isis meeting some people raised the question whether Homenet WG want to support multiple IGP auto-configuration mechanisms.
>
> I checked the meeting minutes of the last Homenet meeting. And found the status of the issue is:
> - WG had decided to have both a configuration protocol (HNCP) + a routing protocol
> - WG hasn't decided to have only one routing protocol or two, or even N...
> - it seems only one routing protocol has more support
>
> May I ask a couple of questions:
>
> 1) Is it necessary to enforce only one routing protocol?
> If HNCP is adopted, I guess multiple routing protocols could be easily supported ?
> I think it might be more flexible if homenet router support multiple routing protocols. Is there any harm?
> (Note: supporting multiple routing protocols here doesn't mean they need run at the same time, just more choices.)
>
> 2) If we decide to have only one, then what is the criteria for protocol selection?
>
> Look forward to your comments. Many thanks.
>
> Best regards,
> Bing
>
>
>
I use IS-IS in a provider setting, where it has advantages.

There is already a draft in 6man regarding how to signal SADR routes to 
end nodes http://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-01

I am of the opinion that the need to communicate source address based 
routing information to end nodes in Homenet will only increase, or else 
it will turn out that there will be many more end nodes that should 
actually be mobile Homenet routers e.g. mobile phones with multiple 
radios and fixed dock connections. The logical step then from IS-IS 
would be that these devices either speak ES-IS or translating metrics 
into RA or running IS-IS on end devices.

With that in mind, I think it would be harmful to add a requirement for 
Homenet routers (and perhaps many mobile nodes) to speak an OSI protocol.
It's yet another protocol stack, we already have alternatives, and it 
isn't widely supported on many operating systems out of the shrink wrap.

-- 
Regards,
RayH