Subject: Re: [homenet] Moving forward.

From: Dino Farinacci <[email-masked]>
Date: Tue, 4 Aug 2015 10:32:14 -0700

> But if we go for IS IS we're apparently going to have to wait (perhaps forever) to get L3 routing over WIFI working/ stable. Something that we've pointedly failed to do in professionally managed office networks in the last 20 years.

What is so unstable about it? 

I could guess you are referring to the lack of multicast performance over wifi. If not, please be clear about “L3 routing over WIFI working/stable” means. 

Otherwise, IS-IS will send multicast frames pretty much at the rate that ND would. So I don’t know what the big fuss about how multicast control protocols, in general, don’t work well.

Dino

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Aug 2015 14:01:00 -0400

> I could guess you are referring to the lack of multicast performance over wifi. If not, please be clear about “L3 routing over WIFI working/stable” means. 

How often does a typical link over which IS-IS operates drop an IS-IS packet?

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 4 Aug 2015 11:22:58 -0700

> On Aug 4, 2015, at 11:01 AM, Ted Lemon <[email-masked]> wrote:
> 

A question for a question.

IS-IS hellos are sent by default roughly every 10 seconds. CSNPs to keep the link-state database in sync is sent every 10 seconds. And all LSPs are sent on demand when there is a link or neighbor change.

Links and boxes should not go down often in a homenet, so there won’t be a high-rate of packets. This, I believe is a safe assumption. The size of an IS-IS LSP will be a function of not only the number of links and routers in the topology, but any other information that is needed to be conveyed (quite possibly device IDs, names, capabilityes, multicast group addresses).

Dino

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Aug 2015 15:29:54 -0400

Dino Farinacci <[email-masked]> wrote:
    > Links and boxes should not go down often in a homenet, so there
    > won't
    > be a high-rate of packets. This, I believe is a safe assumption. The

I don't agree.

Cables are plugged and unplugged on a regular basis, and unplug/replug is a
good first "what's wrong with my network" before going to see if the DSL
model is still alive...  Now you wonder what the cable on my laptop has to do
with Homenet... well, because my laptop is running virtual machines, and
since I want them on the network, I'd have a homenet daemon on my laptop.

Lots of non-technical people unplug all the cables from their router in order
to power cycle it, because... who knows which wire is the important one?

Old people are never quite sure if the RJ45 is seated properly, I've noticed,
so they might replug each cable a few times over a one minute interval.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: David Oran <[email-masked]>
Date: Tue, 4 Aug 2015 15:47:05 -0400

> On Aug 4, 2015, at 3:29 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
What you describe isn’t “often” on the timescales of the distributed protocols. A human can only plug and unplug things on timescales of seconds, not milliseconds, and I think Dino was referring to high-fequency non-human events that can cause links and boxes to flap.

I can’t say for certain, but my old ISIS code would certainly not be unhappy with up/down events on the order of one every second or a few seconds.

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

---

From: [email-masked]
Date: Tue, 4 Aug 2015 13:26:51 -0700

> On Aug 4, 2015, at 12:47 PM, David Oran <[email-masked]> wrote:
> 
> I think Dino was referring to high-fequency non-human events that can cause links and boxes to flap.

Right. If we had route flaps once a minute, I would consider that not often. 

Dino

---

From: Teco Boot <[email-masked]>
Date: Wed, 5 Aug 2015 08:35:35 +0200

> Op 4 aug. 2015, om 20:22 heeft Dino Farinacci <[email-masked]> het volgende geschreven:
> 
> IS-IS hellos are sent by default roughly every 10 seconds. CSNPs to keep the link-state database in sync is sent every 10 seconds. 

The sample or default timers are not optimal for todays wired links. We cannot trust on lower layer state (driver issues, switches). I suggested (hello=1,dead=4) some years ago. Acee responded this is topic for further discussion.
http://www.ietf.org/mail-archive/web/homenet/current/msg01961.html
Resulted in "Minimising convergence time should be a goal" in RFC 7368.

At last IETF, Henning hacked olsrd2, now it has better zero-conf and it has SADR. I tested using a homenet scenario (NRL core simulation). olsrd2 converged much faster than ospf6d. Both ran with defaults, as mandatory in homenet.

My 2ct on RP requirement for convergence speed: 1-hop convergence should be within 5 seconds, network wide convergence within 15 seconds. Reasoning: this is _additional_ time in the total boot procedure.

Another 2ct: during convergence, there should not be looped packets. Reasoning: especially on shared media such as wireless, looped packets effect RP behavior and other user traffic badly, and thus result in bad user experience.

Teco

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Aug 2015 08:50:32 +0200 (CEST)

On Tue, 4 Aug 2015, Ray Hunter wrote:

> As someone who spent rather a lot of time wordsmithing Section 3.5 of RFC7368 
> into something that could reach rough consensus, I find this discussion 
> rather depressing. Section 3.5 was the list of requirements we could agree on 
> when the architecture document shipped. I've been on record as being 
> agnosting in the choice of routing protocol, and hope(d) the DT would deliver 
> us from stalemate, so I remained silent.

We have been trying to address all objections to ISIS by addressing the 
few things that were not already there. Yet, people keep arguing.

> Now I see a lot of super-heavyweight industry names seemingly failing to grok 
> Homenet in general, and specifically the use case of WIFI as a home backbone.

What makes you say this, especially in light of what was presented at the 
last IETF?

> But if we go for IS IS we're apparently going to have to wait (perhaps 
> forever) to get L3 routing over WIFI working/ stable. Something that we've 
> pointedly failed to do in professionally managed office networks in the last 
> 20 years.

Again, what makes you say this?

I keep hearing that babel is loop free and that this is a great feature. 
My take on that is that it's a great feature when wifi just sucks and keep 
going bad and keeps going away and coming back, and you're happy if a few 
packets are delivered once every now and then. When I say this, Juliuz 
says I am silly.

I make sure my wifi works 99.9% or more of the time. Unless it always 
works, it's useless to me. I don't see why isis+wifi-backbone couldn't be 
used in my home (not that I will do that, but if I would).

So again, with basic features like setting the metric depending on 
interface speed and type (which has been around for 15-20 years for 
routing protocols in all kinds of places), what is it that babel would 
actually give us in a decently working homenet with wifi backbone?

ISIS will handle just fine when people unplug and plug cables back in. 
Field engineers have been doing this (badly) forever, ever since people 
started doing computer networking.

I will yield that babel is better in a mesh network where all bets are 
off, but is that really the kind of network we expect people to have? The 
Internet is moving towards supporting real time communication that must 
always work. Yet, I keep hearing that this isn't the homenet we're 
expecting to have? Or what am I missing?

> On the flip side I don't see barriers to Babel running on small cabled 
> networks.

I keep hearing this. As far as I know, nobody has ever said babel wouldn't 
run on cabled networks. I don't see why this point is repeated, nobody is 
arguing with this point.

> In short: I largely agree with Ted, but I see the WIFI backbone use case 
> as a killer differentiator for Homenet (regardless of the final choice 
> of routing protocol). If IS IS can't deliver on that, then it's a real 
> miss.

It can.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Aug 2015 08:53:13 +0200 (CEST)

On Wed, 5 Aug 2015, Teco Boot wrote:

> Another 2ct: during convergence, there should not be looped packets. 
> Reasoning: especially on shared media such as wireless, looped packets 
> effect RP behavior and other user traffic badly, and thus result in bad 
> user experience.

When I was in TSVWG they said that there were 4 different "QoS" classes 
on wifi. The default is to run the routing protocol in the highest QoS 
class. Thus, I don't see this as a huge problem, the routing protocol 
should always be treated with the highest priority. I expect HNCP to be 
run in the same class as well.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Aug 2015 19:16:23 +1200

> Right. If we had route flaps once a minute, I would consider that not often. 

What about a lousy wireless link that drops, say, one packet in two?

   Brian

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 05 Aug 2015 09:51:54 +0200

> I will yield that babel is better in a mesh network where all bets are off

Mikael, I have repeatedly asked you to stop caricaturing our position.
Lossy links exist, and while we expect a home network to have a stable
backbone, topologies such as the one that I described in Section 7 of
draft-mrw-homenet-rtg-comparison-02 are likely to occcur naturally, and
such topologies are not handled adequately by the implementations of IS-IS
that I have had a chance to inspect.

If you disagree with this position on technical grounds, please argue using
technical arguments.  Repeating the same strawman over and over again just
makes you sound like a paid propagandist.

-- Juliusz

---

From: Erik Kline <[email-masked]>
Date: Wed, 5 Aug 2015 17:07:50 +0900

On 29 July 2015 at 16:59, Juliusz Chroboczek
<[email-masked]> wrote:
>> ISIS is many network topologies including mesh?
>
> There are mesh extensions for ISIS?  Interesting, could I please have
> a pointer to that work?

To add to that: has there ever been any evaluation/participation of
IS-IS at Battle Mesh?

---

From: Dave Taht <[email-masked]>
Date: Wed, 5 Aug 2015 11:15:05 +0200

> To add to that: has there ever been any evaluation/participation of

No sign of ISIS here. OLSR, batman, and babel in abundance.
wlan-slovenia is olsr, for example:

https://nodes.wlan-si.net/network/map/#lat=46.17&long=14.960000000000036&zoom=8&type=&project=1,3,6,7,8,9,10,11,13,15,18,19,20,21,23,24,25&status=up,visible,down,duped,new,pending

There are a ton of battlemesh conference videos coming available (I'll
find the channel)

One of the most interesting things to crop up so far was the koruza
free space optics 1gig system..

http://koruza.net/

The conference organizers have had a heck of a time wedging 100 wifi
geeks into a string of uplinks to the internet from this remote
location... and it turned out that it was the wired nets, not the
wireless ones, that was the most trouble so far!

http://ml.ninux.org/pipermail/battlemesh/2015-August/003669.html

-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Aug 2015 11:22:20 +0200 (CEST)

> makes you sound like a paid propagandist.

So I have now re-read that text. There is work ongoing for the ISIS 
implementation to talk to the wireless layer and include quality 
measurements, and I have just taken for granted that the implementation 
will have speed related metrics.

So yes, I agree with the text in there, it's just doesnt reflect current 
state of affairs anymore.

So let me bring up another point, which struck me when I read "works well 
in babel". Our ISIS implementation is tested against a commercial grade 
test suite with 1000+ test cases to check that the implementation does 
what it should. How will future implementors of babel test their 
implementations against what's in the standards?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Aug 2015 12:08:10 +0200 (CEST)

On Wed, 29 Jul 2015, STARK, BARBARA H wrote:

>
> I continue to be confused about the vast array of what is possible in a 
> top-of-the-line IS-IS deployment, and what is being proposed for a 
> small-scale homenet solution. It would be really nice if someone who has 
> created a homenet-sized IS-IS implementation could describe exactly what 
> it can do. What "diagnostics" are in the homenet-sized IS-IS? Can the 
> homenet-sized IS-IS handle mesh topology? Etc. We know *exactly* what 
> Babel is at this point in time. I'm totally clueless as to what the 
> capabilities of a homenet IS-IS are at this time.

At previous BnB we have shown ISIS topology graph tool running under 
OpenWRT that showed the ISIS topology in the OpenWRT web ui. Since ISIS is 
very extensible, we could put other information into it in the future if 
we want to. Since it's not in the homenet charter to require changes in 
end systems, it's hard to argue functionality that could be gained by 
installing new software on end systems, but that's one future possibility.

> And then, if people want to talk about additional hypothetical IS-IS 
> capabilities that could be added to a homenet IS-IS, I think they should 
> be required to describe how much memory and other resources would be 
> needed to include that in a homenet IS-IS. Otherwise, it's completely 
> irrelevant that some IS-IS implementation somewhere does such a thing.

If we want that kind of functionality it's going to require memory+cpu, 
and I don't see how implementing it in ISIS would require significant more 
memory than to implement it in some third protocol running in the home 
(since DNCP isn't well suited for rapid changes (I'm told), it doesn't 
seem like it's a great fit for that).

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 5 Aug 2015 13:13:50 +0300

On 5.8.2015, at 13.08, Mikael Abrahamsson <[email-masked]> wrote:
>> And then, if people want to talk about additional hypothetical IS-IS capabilities that could be added to a homenet IS-IS, I think they should be required to describe how much memory and other resources would be needed to include that in a homenet IS-IS. Otherwise, it's completely irrelevant that some IS-IS implementation somewhere does such a thing.
> If we want that kind of functionality it’s going to require memory+cpu, and I don't see how implementing it in ISIS would require significant more memory than to implement it in some third protocol running in the home (since DNCP isn't well suited for rapid changes (I'm told), it doesn't seem like it's a great fit for that).

If we want to be very explicit about it, _worst-case_ behavior of DNCP is about same of your typical naive link-state protocol; it spams link about updates, and nodes synchronize their state.

To gain bandwidth minimization benefits it provides (while still ensuring relatively rapid convergence even in face of packet loss) that Trickle provides, less frequently changing data is useful (but not mandatory).

IS-IS does not really bring much to the table here that I can see.

Cheers,

-Markus

---

From: Teco Boot <[email-masked]>
Date: Wed, 5 Aug 2015 16:27:07 +0200

> Op 5 aug. 2015, om 08:53 heeft Mikael Abrahamsson <[email-masked]> het volgende geschreven:
> 
> When I was in TSVWG they said that there were 4 different "QoS" classes on wifi. The default is to run the routing protocol in the highest QoS class. Thus, I don't see this as a huge problem, the routing protocol should always be treated with the highest priority. I expect HNCP to be run in the same class as well.

Please push your patches in mainstream kernel...
If you did not patch your kernel, how serious should I take your mails?

Please think twice before you response. Better: show me your working code, I am all in for validation. Private mails is OK.

Teco 

PS. It could be a tough job to get bursty multicast frames in AC_VO. At least it needs a shaper for xx% of airtime.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Aug 2015 16:36:26 +0200 (CEST)

On Wed, 5 Aug 2015, Teco Boot wrote:

> PS. It could be a tough job to get bursty multicast frames in AC_VO. At 
> least it needs a shaper for xx% of airtime.

Why multicast?

---

From: Teco Boot <[email-masked]>
Date: Wed, 5 Aug 2015 16:59:14 +0200

> Op 5 aug. 2015, om 08:50 heeft Mikael Abrahamsson <[email-masked]> het volgende geschreven:
> 
> So again, with basic features like setting the metric depending on interface speed and type (which has been around for 15-20 years for routing protocols in all kinds of places), what is it that babel would actually give us in a decently working homenet with wifi backbone?

Thanks for bringing me up more input for the requirements document:

   Seen the requirement to support a mix of link types 
   in a homenet, with possibly indeterministic, asymmetric 
   and non-transitive links, the RP MUST support per
   neighbor metics. The metric itself is provided by 
   the sub-IP layer, or in case of lack of such capability,
   the RP MUST perform a best effort estimate. Example of
   estimates are the widely used ETX (community networks) or
   delay based estimates. The RP SHOULD implement hysteresis 
   and dampening and SHOULD limit oscillations.

   Even if the sub-IP layer provides link metrics, the RP 
   SHOULD validate correctness. For example, in a bridged
   environment the sub-IP layer might indicate a high speed
   high reliable link towards an IP neighbor, while this
   node is actually reachable over a lossy and low rate link.
   Examples of such is an WiFi access point topology, where 
   stations do not know link metric between the AP and other 
   possibly far stations, and an ethernet attached powerline 
   repeater.

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 5 Aug 2015 17:27:50 +0200

> Op 5 aug. 2015, om 16:36 heeft Mikael Abrahamsson <[email-masked]> het volgende geschreven:
> 

At least discovery needs multicast. LSDB sync can be unicast. There is code for IS-IS for that, right?
Having unicast LSDB sync in AC_VO could be less hard to implement and adopted. IMHO it SHOULD have a shaper, based on airtime.

This results in RP requirements, for having good support for WiFi (or other 802.11 modes, other wireless links).

   The RP MUST support wireless media, where multicast rate 
   is typically at a low rate and could be lossy. Bulk transfer, 
   e.g. LSDB synchronization, MAY make use of unicast mode, 
   with adaptive rate and a retransmit scheme in case of packet 
   loss. For relayed messages, a jitter mechanism SHOULD be used
   to desynchronize for collision avoidance.

   In case of queued or lost packets, path calculation could get
   desynchronized and packet loops may occur. The RP SHOULD 
   circumvent such convergence problems.

Teco

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Aug 2015 18:45:09 +0200 (CEST)

> At least discovery needs multicast. LSDB sync can be unicast. There is code for IS-IS for that, right?

Yes.

>   is typically at a low rate and could be lossy. Bulk transfer,

Then I guess we need this requirement for the IP protocol(s) that are 
being set up using the routing protocol as well. How well does IPv6 work 
in the environments you're used to and trying to work around with these 
requirements?

>   to desynchronize for collision avoidance.

Why does the L3 layer need to do collision avoidance? I thought this was 
up to L2 to do.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 5 Aug 2015 09:51:50 -0700

You have to decide what your interface damping algorithm is if this link is not considered down by the implementation. If you can observe 50% packet loss in a short period of time, the implementation should take the link down and allow the IGP to converge to a new path.

If there aren’t enough redundant paths in the home network, then you have to live with 50% loss.

Do you all think hosts will be multi-homed to more than one wifi radio?

Dino

> On Aug 5, 2015, at 12:16 AM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 5 Aug 2015 09:52:20 -0700

> On Aug 4, 2015, at 11:35 PM, Teco Boot <[email-masked]> wrote:
> 
> 

That is fine. My claim still stands.

Dino

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Aug 2015 13:12:56 -0400

David Oran <[email-masked]> wrote:
    > What you describe isn't often on the timescales of the distributed
    > protocols. A human can only plug and unplug things on timescales of
    > seconds, not milliseconds, and I think Dino was referring to
    > high-fequency non-human events that can cause links and boxes to flap.

I mostly agree; my experience in enterprises is that OSPF could deal with
human-scale cable plugging, but that stock-STP could not. (RSTP could be
tuned to deal, but not all vendors gave me enough knobs: which is why we used
OSPF).

But, Dino's original query didn't specify a time scale.

    > I can't say for certain, but my old ISIS code would certainly not be
    > unhappy with up/down events on the order of one every second or a few
    > seconds.

Took me awhile to parse the double negative to say:
     my old ISIS code would certainly be happy with up/down events on the
     order of one every second or a few seconds.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Aug 2015 15:18:17 -0400

Dino Farinacci <[email-masked]> wrote:
    > You have to decide what your interface damping algorithm is if this
    > link is not considered down by the implementation. If you can observe
    > 50% packet loss in a short period of time, the implementation should
    > take the link down and allow the IGP to converge to a new path.

    > Do you all think hosts will be multi-homed to more than one wifi radio?

Yes, having seperate 2.4Ghz and 5Ghz radios is common.
Historically CPEs have bridged the two, but that isn't a great idea.

(That's why Dave Taht wants you guys to get an OpenWRT device out and try it,
because this kind of thing would be obvious)

---

From: Teco Boot <[email-masked]>
Date: Thu, 6 Aug 2015 16:26:08 +0200

> Op 5 aug. 2015, om 21:18 heeft Michael Richardson <[email-masked]> het volgende geschreven:
> 
> 

WiFi is build on the assumption that single SSID is singe IP subnet and that stations can roam between AP's without loss of connections. I think this is great.

Meanwhile I have installed an enterprise grade WLAN controller, providing pretty good service in my house. 3 dual radio high-end 11ac AP's. Costs me much more than couple of high end home routers, but at least I have trouble-free wireless Internet access for my mobile gear.

I don't say WLC solves all problems. AP's need a backbone. Could be mix of whatever.

Teco

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 6 Aug 2015 08:42:16 -0700

> WiFi is build on the assumption that single SSID is singe IP subnet and that stations can roam between AP's without loss of connections. I think this is great.

We can do this today when LISP runs on the device. And you only need a single IPv6 address!

I am asking the question because I want to get a feel from this list if they think multi-homing (per-node) may be popular in the home (in addition or instead multi-homing the home).

> Meanwhile I have installed an enterprise grade WLAN controller, providing pretty good service in my house. 3 dual radio high-end 11ac AP's. Costs me much more than couple of high end home routers,…

Cool.

> I don't say WLC solves all problems. AP's need a backbone. Could be mix of whatever.

I use a Raspberry-PI that routes between wifi and ethernet interfaces.

Dino

---

From: Ray Hunter <[email-masked]>
Date: Thu, 06 Aug 2015 21:11:59 +0200

Mikael Abrahamsson <mailto:[email-masked]>
> 5 August 2015 08:50
>> As someone who spent rather a lot of time wordsmithing Section 3.5 of 
>> RFC7368 into something that could reach rough consensus, I find this 
>> discussion rather depressing. Section 3.5 was the list of 
>> requirements we could agree on when the architecture document 
>> shipped. I've been on record as being agnosting in the choice of 
>> routing protocol, and hope(d) the DT would deliver us from stalemate, 
>> so I remained silent.
>
> We have been trying to address all objections to ISIS by addressing 
> the few things that were not already there. Yet, people keep arguing.
>
I'm not arguing against IS IS. But I think the IS IS proponents have 
singularly failed to clearly express what is proposed for Homenet.

To my mind that has now been largely corrected with

https://tools.ietf.org/html/draft-lamparter-homenet-isis-profile-00

Although there are an awful lot of current ID drafts in the "must 
implement" list.

And there are still gaps e.g. How to set metrics. How to handle security.

>> Now I see a lot of super-heavyweight industry names seemingly failing 
>> to grok Homenet in general, and specifically the use case of WIFI as 
>> a home backbone.
>
> What makes you say this, especially in light of what was presented at 
> the last IETF?
This thread.
>
>> But if we go for IS IS we're apparently going to have to wait 
>> (perhaps forever) to get L3 routing over WIFI working/ stable. 
>> Something that we've pointedly failed to do in professionally managed 
>> office networks in the last 20 years.
>

Ted's mail of Sat, 25 Jul 2015 21:07:43 -0400
>
> I keep hearing that babel is loop free and that this is a great 
> feature. My take on that is that it's a great feature when wifi just 
> sucks and keep going bad and keeps going away and coming back, and 
> you're happy if a few packets are delivered once every now and then. 
> When I say this, Juliuz says I am silly.
>
> works, it's useless to me. I don't see why isis+wifi-backbone couldn't 
> be used in my home (not that I will do that, but if I would).
>
> Field engineers have been doing this (badly) forever, ever since 
> people started doing computer networking.
>
I'm not talking about cables. I've run serious IS IS backbone networks 
(together with MPLS). I know what IS IS can do in that sort of 
environment. It's a great protocol.
> off, but is that really the kind of network we expect people to have? 
> The Internet is moving towards supporting real time communication that 
> must always work. Yet, I keep hearing that this isn't the homenet 
> we're expecting to have? Or what am I missing?
>
The Internet is also going wireless.
>> On the flip side I don't see barriers to Babel running on small 
>> cabled networks.
>
> I keep hearing this. As far as I know, nobody has ever said babel 
> wouldn't run on cabled networks. I don't see why this point is 
> repeated, nobody is arguing with this point.
Because Babel seems to do what IS IS can, plus more. If that's not the 
case, then I'd like to see how IS IS can run in lossy and mesh networks.
>
>> In short: I largely agree with Ted, but I see the WIFI backbone use 
>> case as a killer differentiator for Homenet (regardless of the final 
>> choice of routing protocol). If IS IS can't deliver on that, then 
>> it's a real miss.
>
> It can.
I guess this is a "show me" moment.

Where can I download the code to test on Openwrt?

regards,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Aug 2015 08:32:34 +0200 (CEST)

> Where can I download the code to test on Openwrt?

The isis Openwrt repo is at:

https://git-us.netdef.org/projects/OSR/repos/openwrt-isis-hnet/browse

So, depending on what you mean by "the code", it's there. What were you 
looking for, the most recent development isn't there yet I believe.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Aug 2015 08:53:48 +0200 (CEST)

On Thu, 6 Aug 2015, Ray Hunter wrote:

>>> Now I see a lot of super-heavyweight industry names seemingly failing to 
>>> grok Homenet in general, and specifically the use case of WIFI as a home 
>>> backbone.
>> 

Well, I am still of the opinion that ISIS would work well without 
modifications for Wifi that works as intended. It's also been that when I 
have questioned why people would have crappy wifi (which is seems to be 
one of babels major design goals to handle), I have been told I am being 
silly and that's not what's being said. It's been quite confusing.

Also, the homenet architecture document doesn't state that the routing 
protocol must handle the kind of adverse conditions some people in here 
seem to take for granted:

3.3.3.  Handling Varying Link Technologies

    Homenets tend to grow organically over many years, and a homenet will
    typically be built over link-layer technologies from different
    generations.  Current homenets typically use links ranging from 1
    Mbit/s up to 1 Gbit/s -- a throughput discrepancy of three orders of
    magnitude.  We expect this discrepancy to widen further as both high-
    speed and low-power technologies are deployed.

    Homenet protocols should be designed to deal well with
    interconnecting links of very different throughputs.  In particular,
    flows local to a link should not be flooded throughout the homenet,
    even when sent over multicast, and, whenever possible, the homenet
    protocols should be able to choose the faster links and avoid the
    slower ones.

    Links (particularly wireless links) may also have limited numbers of
    transmit opportunities (txops), and there is a clear trend driven by
    both power and downward compatibility constraints toward aggregation
    of packets into these limited txops while increasing throughput.
    Transmit opportunities may be a system's scarcest resource and,
    therefore, also strongly limit actual throughput available.

So claiming some did not "grok homenet" seems to me rather that we have 
had different opinions on what a homenet is/was, but as this has 
progressed we seem to have come closer to actually being in agreement on 
what it is and what the requirements are.

> Because Babel seems to do what IS IS can, plus more. If that's not the case, 
> then I'd like to see how IS IS can run in lossy and mesh networks.

Babel does some of what ISIS does. ISIS does some of what babel does.

>>> as a killer differentiator for Homenet (regardless of the final choice of 
>>> routing protocol). If IS IS can't deliver on that, then it's a real miss.
>> 
>> It can.

Just to be sure again, what are the requirements for "wifi backbone use 
case"? Minimal use of multicast? Metric set so cable is prefered over 
wifi? Or also that it checks regularily if packets can be delivered and 
change metric?

So while I know babel has been "battle proven" for this, I still don't 
know if we have an agreed set of requirements here. Just the same way as I 
have seen ISIS as the obvious choice here because of <factors> that for me 
is obvious and was never written down, it seems to me that this is another 
place where this is obvious to babel proponents what is required, and this 
was never written down either.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 07 Aug 2015 09:44:34 +0200

> wifi? Or also that it checks regularily if packets can be delivered and

These are all implementation details.

We can argue all day about implementation details (and we do, here at
Battlemesh), but at the end of the day, the only thing that counts is
experimental data.

-- Juliusz

---

From: Gert Doering <[email-masked]>
Date: Fri, 7 Aug 2015 13:30:48 +0200

Hi,

> silly and that's not what's being said. It's been quite confusing.

You *are* being silly, because Babels design goal is not "handle crappy 
wifi well" but "handle *all* potential network topologies a homenet might
encounter well, including crappy wifi".  Which means it will totally work
well if you do *not* have a crappy wifi link around.

[..]
> Babel does some of what ISIS does. ISIS does some of what babel does.

What is it that Babel does *not* do that ISIS does (and that is relevant
for a homenet scenario)?  It perfectly well works on wired links.

It might not work on an ISP backbone, and it does not do L2 (TRILL), and
it does not do multi-topology, and it does not run over OSI protocol - but
which of that is relevant for the homenet scenario?

Nobody is doubting that ISIS is the more versatile protocol, has a more
active working group, many more RFCs to document it, and so on - but 
what of this is *relevant* here?

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Aug 2015 14:19:51 +0200 (CEST)

On Fri, 7 Aug 2015, Gert Doering wrote:

> for a homenet scenario)?

This has been stated and dismissed multiple times because of differing 
opinions how important these things are.

For instance, babel does not have an IETF working group. Babel does not 
have a testing suite (as far as I know) to test new implementations 
against how things "should" be. Babel doesn't provide topology. Babel 
doesn't have 10+ independent implementations of the protocol that has been 
shown to interoperate. Babel is an experimental RFC protocol.

None of this is a hard requirement according to the homenet architecture 
document. Neither is some other things that proponents of babel bring 
forth is really important and unique selling point for babel.

We don't have agreement on what homenet should be, what it looks like, 
what the requirements are, how it's implemented, and what's important over 
time. That's why we can't come to agreement on what routing protocol to 
choose.

---

From: Gert Doering <[email-masked]>
Date: Fri, 7 Aug 2015 14:22:38 +0200

Hi,

> time. That's why we can't come to agreement on what routing protocol to 

To me, the main reason seems to be that a very vocal minority insists that
it absolutely *has* to be IS-IS...

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Aug 2015 14:30:58 +0200 (CEST)

On Fri, 7 Aug 2015, Gert Doering wrote:

> To me, the main reason seems to be that a very vocal minority insists 
> that it absolutely *has* to be IS-IS...

Yes, it's a lot easier to reach agreement on one solution if people with 
differing opinion shut up and go away.

Are you seriously saying that people who are saying it *has* to be babel 
isn't a very vocal minority as well?

---

From: Gert Doering <[email-masked]>
Date: Fri, 7 Aug 2015 14:37:17 +0200

Hi,

> differing opinion shut up and go away.

So true.

> isn't a very vocal minority as well?

I see a number of people working hard on drafts and code, and demonstrating
that Babels gets the job done.  And I see a few people insisting on IS-IS,
no matter what collateral damage they do.

YMMV, of course.

Gert Doering
        -- NetMaster

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 08 Aug 2015 02:59:20 +0200

> No sign of ISIS here. OLSR, batman, and babel in abundance.

Battlemesh tests are done in a pure mesh topology (with non-transitive
links), so IS-IS wouldn't work here.  (This is not an argument against
IS-IS in Homenet, btw, since pure mesh is most probably out-of-charter for
Homenet.)

> wlan-slovenia is olsr

They're migrating to Babel, with a few dozen nodes already running OLSR
and Babel simultaneously.  (Yeah, they're that good.)

-- Juliusz

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 16:32:54 +0900

> it absolutely *has* to be IS-IS...

That has been my perception as well. I'm afraid I can't put that many names
to it. Mikael obviously comes to mind, and perhaps David Lamparter, but I
can't think of many other WG participants who are in the same camp.

I think that if the WG had voted on this question, or we had gone with
rough consensus, we would have picked babel a long time ago... if it had
not been that the IS-IS camp has successfully argued that IETF procedure
("we can't standardize something that is not a standard") means that babel
cannot be picked at this time.

As someone who doesn't have a favourite routing protocol and doesn't have a
horse in this race, I perceive this to cause two problems.

First, we as a WG can never ship anything, because as always in the IETF, a
vocal minority with a semi-reasonable argument can always block any
proposal (and please don't respond with the standard counterargument that
rough consensus doesn't mean unanimity, that chairs are free to call
consensus, etc. etc... I know all that's true in theory, but it doesn't
actually work in practice, having been in vocal minorities myself). Nobody
can build / ship babel for as long as there is a credible threat that the
IETF will eventually decide to use IS-IS.

Second, even if the majority were to cave into the vocal minority we were
to cave in and use IS-IS, we'd end up with a worse choice, because the
reality is that the homenet-capable *implementations* of IS-IS are way
behind homenet-capable *implementations* of babel in terms of important
metrics such as memory footprint, open-source licensing and proven ability
to function well on lossy wireless links.

Chairs - what do you think would happen if you called rough consensus on
babel based on the maturity of the running code? Is it even a practical
possibility for you to do so, or is that option out of your reach for as
long as the design team continues to exist?

---

From: Ray Bellis <[email-masked]>
Date: Mon, 10 Aug 2015 09:08:56 +0100

> long as the design team continues to exist?

[my view only - Mark is on vacation in the US at the moment]

As I understand it, as things stand we would be required to make any
Homenet document that normatively required Babel to be on the
Experimental Track rather than Proposed Standard.

I believe that would remain the case even if the DT makes a firm
recommendation in favour of Babel.

Overcoming that hurdle (by standardising Babel) is primarily a layer 9
issue, and outside this WG's control.  However many of the proponents
and potential users of Babel are active in this WG and I would urge them
to participate in the new non-WG Babel list and actively work towards
that goal.

Whilst not wanting to de-rail any effort to standardise Babel (since I
firmly believe it should be standardised), I'd like to hear the WG's
view on having part of our Homenet stack be on Experimental Track
instead of PS.  E.g., would it affect vendors' willingness to implement
Homenet, etc?

Ray

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 17:20:12 +0900

> instead of PS.  E.g., would it affect vendors' willingness to implement

Personally I doubt that in the market segment we're talking about (which
includes many vendors that just take open source implementations, integrate
them, and ship them) vendors will understand or care about the difference
between an experimental RFC and a standards track RFC. Though of course,
not being one of those vendors, my opinion is in no way authoritative.

---

From: Erik Kline <[email-masked]>
Date: Mon, 10 Aug 2015 17:23:45 +0900

> instead of PS.  E.g., would it affect vendors' willingness to implement

+1

Especially if that got us to a place where 2-3 years from now we could
publish {D,H}NCPbis incorporating lessons learned and whatnot as a
Proposed Standard, I think that would be a perfectly acceptable
outcome.

My reading of https://tools.ietf.org/html/rfc7282 suggests to me that
we do have a way forward here.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 11 Aug 2015 10:12:19 +0200

Hi,

> Op 10 aug. 2015, om 10:20 heeft Lorenzo Colitti <[email-masked]> het volgende geschreven:
> 
> Personally I doubt that in the market segment we're talking about (which includes many vendors that just take open source implementations, integrate them, and ship them) vendors will understand or care about the difference between an experimental RFC and a standards track RFC. Though of course, not being one of those vendors, my opinion is in no way authoritative.

The CPE vendor that I worked with on IPv6 features definitely wouldn't care as long as they could sell a 'cool feature' to their customers.

> Op 10 aug. 2015, om 10:23 heeft Erik Kline <[email-masked]> het volgende geschreven:
> 

+1

Sander

---

From: Tore Anderson <[email-masked]>
Date: Tue, 11 Aug 2015 10:21:16 +0200

* Sander Steffann <[email-masked]>

> >> Whilst not wanting to de-rail any effort to standardise Babel
> >> (since I firmly believe it should be standardised), I'd like to
> >> hear the WG's view on having part of our Homenet stack be on
> >> Experimental Track instead of PS.  E.g., would it affect vendors'
> >> willingness to implement Homenet, etc?
> > 
> > +1
> > 
> > Especially if that got us to a place where 2-3 years from now we
> > could publish {D,H}NCPbis incorporating lessons learned and whatnot
> > as a Proposed Standard, I think that would be a perfectly acceptable
> > outcome.
> 
> +1

Indeed.

Experimental Track would at least mean being on *a* track, which is
more than could be said about the status quo, IMHO.	

Tore

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 11 Aug 2015 12:49:37 +0000

+1

I've worked with a variety of router vendors over the years. They tend to be a very pragmatic bunch, who are more concerned with interoperability, stability, market-demand, and cost to implement (processing, memory, labor), than they are concerned with the track of an RFC. Operators also tends not to care. My expectation is that if IETF can publish a recommendation, operators can go to their respective industry groups (BBF, CableLabs) and put a requirement in their TR-124/eRouter specs to drive the capability into ISP-procured CE routers. If cost of implementation is low enough, consumer electronics manufacturers (some of whom also sell to ISPs) are likely to follow.

But if IETF picks 2 and ISPs then pick 1 to promote (assuming ISPs could agree on 1), the consumer electronics industry may be less likely to follow. I've seen a lot of resistance to implementing features that make it easy for ISPs to take control of a home network without user involvement (e.g., ISP setting routing and QoS policy, unfettered visibility of the home network, etc.). 
Barbara

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Aug 2015 12:30:16 -0400

Dino Farinacci <[email-masked]> wrote:
    >> WiFi is build on the assumption that single SSID is singe IP subnet
    >> and that stations can roam between AP's without loss of connections. I
    >> think this is great.

    > I am asking the question because I want to get a feel from this list if
    > they think multi-homing (per-node) may be popular in the home (in
    > addition or instead multi-homing the home).

Nodes multihome already now, it just doesn't work that well.
wired, different radio frequencies...

Two APs in the home easily see three links between them today:
    2.4Ghz, 5Ghz, wired

to that you might also have the latest powerline stuff (which is a wired
version of 802.15.4), 15.4 linkages that may come and go, maybe even BTLE.

In my neighbourhood, someone's "wireless" ("FIBE") TV SSID seems to obliterate
much of the wireless bandwidth; but I guess only when they are watching
something.  My WIIU/Netflix is wired for this very reason.

    > I use a Raspberry-PI that routes between wifi and ethernet interfaces.

Routing is such a better thing, and I sure would like to use LISP.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Aug 2015 09:21:49 -0700

> Nodes multihome already now, it just doesn't work that well.

Well I realize that.  ;-)

I am just wondering if multi-homed devices will use one interface but multi-home their sites at home. So I’m wondering if host multi-homing versus site multi-homing will be more popular.

> version of 802.15.4), 15.4 linkages that may come and go, maybe even BTLE.

But each device COULD be attached to one of these many layer-2 media. I am not sure there is much value to multi-home the hosts versus just having multiple links that are connected together with router(s).

> something.  My WIIU/Netflix is wired for this very reason.

You don’t have pleasant neighbors.  ;-)

> Routing is such a better thing, and I sure would like to use LISP.

You are preaching to a 20-year routing bigot. Every time people go with extended L2 networks, they realize they make a mistake, time goes on, and then they do it again. Now in mid-2010s, VXLAN is the mistake, or I should say L2-overlays.

Now I have to convince Peter that L2TP is the same mistake in DT data centers. But I know what the answer is, “we have to support what the user wants”. But you can make people think they are local using L3 overlays. And fuckin ARP and ND don’t have to go everywhere.

Dino

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 11 Aug 2015 16:38:39 +0000

-----Original Message-----
From: homenet [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Tuesday, August 11, 2015 12:22 PM
To: Michael Richardson
Cc: HOMENET
Subject: Re: [homenet] Moving forward.

>And fuckin ARP and ND don’t have to go everywhere.

+1.  

ARP and ND should stick to their link-local domain.

Hemant

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 12 Aug 2015 14:29:24 +0200

> instead of PS.

I'd like to remind folks that Babel has been independently reimplemented
from the spec at least once (and there are some things I'm not allowed to
tell you about yet).  While the spec has a number of editorial flaws, we
have a concise list of the more important ones.

I'd also like to point at the precedent of OLSRv1, which had a high-quality
experimental RFC, and has been widely deployed by vendors and communities.
(Much more so than OLSRv2, although I see with pleasure that Henning's
heroic efforts are finally starting to pay off.)

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 13 Aug 2015 08:39:08 +0300

+1

Actually, as {D,H}NCP do not have RP dependency anymore anyway, all we need is for the ‘homenet router draft’ which refers to HNCP, {Babel,IS-IS}, and S-D stuff (if it will be actually considered mandatory to implement; probably, given the arch draft) to be experimental. This sounds fine by me as well.

Of course, yet another snakepit is the fact that both Babel and IS-IS aspects of solution are partially drafts (source-specific for Babel, various things for IS-IS) and/or unspecified (metrics for IS-IS). And S-D is depending on dnssd hybrid, and and.. I think we’re years out from having such router draft realistically becoming a RFC.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 13 Aug 2015 11:33:20 +0200

I've tried to trim the CC, not sure if the remaining folks are on the list.

> Of course, yet another snakepit is the fact that both Babel and IS-IS
> aspects of solution are partially drafts (source-specific for Babel,
> various things for IS-IS) and/or unspecified (metrics for IS-IS).

The Babel Extension Mechanism became RFC 7557 last May.  Source-Specific
for Babel[1] has been ready for the Editor's consideration since June, I'm
pretty confident it can become an RFC soon.

These are the only dependencies for the Babel variant of Homenet -- the
other extensions are either just nice to have (efficient routing across
multi-radio transit links) or irrelevant to Homenet (efficient routing in
overlay networks).

Granted, those are Experimental RFCs, but they are written in RFC 2119
language, and we've made every effort to make them readable and implementable.

[1] That's draft-boutier-babel-source-specific-01, in case anyone wants to
    do a review.  Go wild, I have a thick skin.