Re: [homenet] Moving forward.

[Juliusz Chroboczek]

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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Markus Stenberg]

On 10.8.2015, at 11.23, Erik Kline  wrote:
>> 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.
> 
> My reading of https://tools.ietf.org/html/rfc7282 suggests to me that
> we do have a way forward here.

+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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Juliusz Chroboczek]

> 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.

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Hemant Singh (shemant)]

-Original Message-
From: homenet [mailto:homenet-boun...@ietf.org] 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Dino Farinacci]

> Dino Farinacci  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.
> 
>> 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).
> 
> 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.

> 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.

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).

> 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.

You don’t have pleasant neighbors.  ;-)

> 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.
> 
> 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

> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Michael Richardson]

Dino Farinacci  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.

> 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).

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 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.

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

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[STARK, BARBARA H]

> > >> 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

+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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Tore Anderson]

* Sander Steffann 

> > Op 10 aug. 2015, om 10:23 heeft Erik Kline  het
> > volgende geschreven:
> > 
> >> 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Sander Steffann]

Hi,

> Op 10 aug. 2015, om 10:20 heeft Lorenzo Colitti  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  het volgende 
> geschreven:
> 
>> 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

Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Lorenzo Colitti]

On Mon, Aug 10, 2015 at 5:08 PM, Ray Bellis  wrote:

> 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?
>

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.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Ray Bellis]

On 10/08/2015 08:32, Lorenzo Colitti wrote:

> 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?

[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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Juliusz Chroboczek]

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

> 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Gert Doering]

Hi,

On Fri, Aug 07, 2015 at 02:30:58PM +0200, Mikael Abrahamsson wrote:
> 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.

So true.

> Are you seriously saying that people who are saying it *has* to be babel 
> 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
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgpuOpL1tMUQG.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Mikael Abrahamsson]

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?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Gert Doering]

Hi,

On Fri, Aug 07, 2015 at 02:19:51PM +0200, Mikael Abrahamsson wrote:
> 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.

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
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgpng_BOByZty.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Mikael Abrahamsson]

On Fri, 7 Aug 2015, Gert Doering wrote:

What is it that Babel does *not* do that ISIS does (and that is relevant 
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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Gert Doering]

Hi,

On Fri, Aug 07, 2015 at 08:53:48AM +0200, Mikael Abrahamsson wrote:
> 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.

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 AGVorstand: 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
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Juliusz Chroboczek]

> 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?

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Mikael Abrahamsson]

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.


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

This thread.


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.


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.


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

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?


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  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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Mikael Abrahamsson]

On Thu, 6 Aug 2015, Ray Hunter wrote:


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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Ray Hunter]

Mikael Abrahamsson 

5 August 2015 08:50
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.


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.


Again, what makes you say this?


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.


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'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.
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?



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,
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Dino Farinacci]

> 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, but at least I have 
> trouble-free wireless Internet access for my mobile gear.

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Teco Boot]

> Op 5 aug. 2015, om 21:18 heeft Michael Richardson  het 
> volgende geschreven:
> 
> 
> Dino Farinacci  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.
> 
>> 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?
> 
> Yes, having seperate 2.4Ghz and 5Ghz radios is common.
> Historically CPEs have bridged the two, but that isn't a great idea.

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


> 
> (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)
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Michael Richardson]

Dino Farinacci  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.

> 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?

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)

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Michael Richardson]

David Oran  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.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Dino Farinacci]

> On Aug 4, 2015, at 11:35 PM, Teco Boot  wrote:
> 
> 
>> Op 4 aug. 2015, om 20:22 heeft Dino Farinacci  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.

That is fine. My claim still stands.

Dino

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Dino Farinacci]

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  
> wrote:
> 
> On 05/08/2015 08:26, farina...@gmail.com wrote:
>> 
>> 
>>> On Aug 4, 2015, at 12:47 PM, David Oran  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. 
> 
> What about a lousy wireless link that drops, say, one packet in two?
> 
>   Brian

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Mikael Abrahamsson]

On Wed, 5 Aug 2015, Teco Boot wrote:


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


Yes.



  The RP MUST support wireless media, where multicast rate
  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?



  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.


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


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Teco Boot]

> Op 5 aug. 2015, om 16:36 heeft Mikael Abrahamsson  het 
> volgende geschreven:
> 
> 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?

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Teco Boot]

> Op 5 aug. 2015, om 08:50 heeft Mikael Abrahamsson  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



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Mikael Abrahamsson]

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?

--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Teco Boot]

> Op 5 aug. 2015, om 08:53 heeft Mikael Abrahamsson  het 
> volgende geschreven:
> 
> 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.

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.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Markus Stenberg]

On 5.8.2015, at 13.08, Mikael Abrahamsson  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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Mikael Abrahamsson]

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).


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Mikael Abrahamsson]

On Wed, 5 Aug 2015, Juliusz Chroboczek wrote:


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.


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?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Dave Taht]

On Wed, Aug 5, 2015 at 10:07 AM, Erik Kline  wrote:
> On 29 July 2015 at 16:59, Juliusz Chroboczek
>  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?

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.9600036&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

> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



-- 
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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Erik Kline]

On 29 July 2015 at 16:59, Juliusz Chroboczek
 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?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Juliusz Chroboczek]

> 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Brian E Carpenter]

On 05/08/2015 08:26, farina...@gmail.com wrote:
> 
> 
>> On Aug 4, 2015, at 12:47 PM, David Oran  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. 

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

   Brian

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Mikael Abrahamsson]

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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Mikael Abrahamsson]

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 Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Teco Boot]

> Op 4 aug. 2015, om 20:22 heeft Dino Farinacci  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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[farinacci]

> On Aug 4, 2015, at 12:47 PM, David Oran  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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[David Oran]

> On Aug 4, 2015, at 3:29 PM, Michael Richardson  wrote:
> 
> 
> Dino Farinacci  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.
> 
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.


> 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 , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Michael Richardson]

Dino Farinacci  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 , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Dino Farinacci]

> On Aug 4, 2015, at 11:01 AM, Ted Lemon  wrote:
> 
> On Aug 4, 2015, at 1:32 PM, Dino Farinacci  wrote:
>> 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?

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Ted Lemon]

On Aug 4, 2015, at 1:32 PM, Dino Farinacci  wrote:
> 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?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Dino Farinacci]

> 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[STARK, BARBARA H]

> >There are mesh extensions for ISIS?  Interesting, could I please have a
> pointer to that work?
> 
> TRILL RBridges using ISIS in a RBridged mesh topology.

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.

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.
Barbara

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Hemant Singh (shemant)]

-Original Message-
From: Juliusz Chroboczek [mailto:j...@pps.univ-paris-diderot.fr] 
Sent: Wednesday, July 29, 2015 3:59 AM
To: Hemant Singh (shemant)
Cc: HOMENET
Subject: Re: [homenet] Moving forward.

>There are mesh extensions for ISIS?  Interesting, could I please have a 
>pointer to that work?

TRILL RBridges using ISIS in a RBridged mesh topology.

Hemant

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Juliusz Chroboczek]

> ISIS is many network topologies including mesh?

There are mesh extensions for ISIS?  Interesting, could I please have
a pointer to that work?

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Hemant Singh (shemant)]

-Original Message-
From: Juliusz Chroboczek [mailto:j...@pps.univ-paris-diderot.fr] 
Sent: Tuesday, July 28, 2015 5:08 AM
To: Hemant Singh (shemant)
Cc: HOMENET
Subject: Re: [homenet] Moving forward.


>Yes, I have.  On one router this is easy.  You obviously need two routers in 
>order to create a loop.

Then why do multiple routers work with ISIS is many network topologies 
including mesh? ISIS works dandy in a RBridged TRILL network as well.  No 
mature routing protocol will re-inject a route received on an interface back 
out the same interface for a route included in a routing update.  Such rules 
are actually included in ISIS routing.  Any other routing developed for a 
commercial grade routing does follow the same rule.

Would you like me to send you a configuration with ISIS MT (ipv4 and ipv6) with 
RIPng on a Cisco router with no redistribution nuance configured?  

As others have said, we could work out a managed IPv6 CE router for its homenet 
properties in CableLabs.   More testing is needed with new routing protocols 
such as Babel for tests such as routing loops, link up/down detection time, 
debugging support, etc.  Do also deploy a test network Babel in the enterprise 
for more testing.  I always want to abstract new routing or disparate routing 
links (lossy vs. not) in a separate routed domain to narrow down issues faster. 
 I am not for any one routing protocol.  Use what the consensus gets to.  

Hemant

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Hemant Singh (shemant)]

-Original Message-
From: Gert Doering [mailto:g...@space.net] 
Sent: Tuesday, July 28, 2015 4:39 AM
To: Hemant Singh (shemant)
Cc: Pierre Pfister; Pascal Thubert (pthubert); Ted Lemon; HOMENET; Terry 
Manderson; Gert Doering; Dino Farinacci; Mikael Abrahamsson
Subject: Re: [homenet] Moving forward.

>This is a totally idiotic idea.

>Sorry to be so blunt, but there is NOTHING to be gained by insisting on "we 
>must use IS-IS somewhere! we'll look long and hard to find a niche where it 
>works, and hammer it in there!".

>Running two different routing protocols in the *homenet* means "totally not 
>understanding what homenet is about".  This is not a managed environment, with 
>Big Name Router Vendors and Big Brains >Routing Code Guys creating products, 
>but *HOME*.  With CPE vendors involved.

When I and others developed the IPv6 CE router RFC in v6ops, our clear mandate 
was to support both managed an un-managed modes in the CE router.  If the 
current focus of homenet folks replying to this thread is the un-managed or 
retail CE router, that is fine.  But why is a managed CE not a goal for the 
homenet?  A SP can send configuration that can be recursively sent to 
downstream nodes in the LAN using, say, the DHCPv6 server in the CE.   This 
discussion has already said a wifi mesh network is expected in the home.   
Well, a wired mesh can also be expected in the home.   I would best debug 
issues is each separate mesh separately and that is why I mentioned the routed 
domains.   By all means, both routed domains can use Babel.   The IPv6 CE 
router already has two routed domains in the WAN and the LAN. 

Thus there is a requirement (f) support managed mode of the IPv6 CE router and 
its routing in the LAN.   A managed IPV6 CE router is likely to do better than 
the retail device. 

Hemant   

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Hemant Singh (shemant)]

Gabriel,

Thanks.  I did read the section.  One comment.  The section says ISIS does not 
support distance vector.   ISIS is a link state routing protocol and thus it 
does not support any distance vector operation.

Hemant

From: Gabriel Kerneis [mailto:kern...@google.com]
Sent: Tuesday, July 28, 2015 1:51 AM
To: Hemant Singh (shemant)
Cc: Juliusz Chroboczek; HOMENET
Subject: Re: [homenet] Moving forward.

Hemant,

On Tue, Jul 28, 2015 at 1:56 AM, Hemant Singh (shemant) 
mailto:shem...@cisco.com>> wrote:
Have you run, say, RIPng, on one network interface facing the interior of a 
network while running IS-IS on another interface on the same router?

Please read Section 
7<https://tools.ietf.org/html/draft-mrw-homenet-rtg-comparison-02#section-7> of 
draft-mrw-homenet-rtg-comparison-02.txt. This link has been posted repeatedly 
on this list in the last few days.

Thanks,
Gabriel



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Paul Duffy]

On 7/28/2015 11:59 AM, STARK, BARBARA H wrote:


It would be possible for a group like BBF or CableLabs to recommend 
something for use in operator-procured devices. In some cases this has 
been effective in getting retail devices also to support (e.g., 
PPPoE). The US cable industry would perhaps be in a better position to 
agree on something, because they seem to be more unified in what they 
seem to think they want. I can definitely say that such unity does not 
exist at BBF. HGI (Home Gateway Initiative) might have been able to do 
this for the subset of operators that belong to it, but HGI says it is 
closing shop in 2016.





Strong agreement. CableLabs could have significant sway to settle this 
matter.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[STARK, BARBARA H]

> My point was simply that the IETF has multiple of … pretty much everything 
> else … the reason why things work is that somebody (an operator group, an 
> industry alliance/forum, …) figure out what is MTI — for their context — and 
> then do that.

> I am simply wondering out loud why that would not, also, work here?

Because homenet is trying to tackle the world of true consumer retail. In the 
US, I suppose it would be possible for CEA to recommend a solution for US 
consumer electronics devices that would maybe/maybe not be adopted by the rest 
of the world (or even by devices sold in the US, since it has no true mandate 
power). But I think it’s unlikely that CEA would try to solve this, unless 
someone (likely not affiliated with a CE provider – given who has been active 
in the discussion in IETF) decides to try to lead them.

It would be possible for a group like BBF or CableLabs to recommend something 
for use in operator-procured devices. In some cases this has been effective in 
getting retail devices also to support (e.g., PPPoE). The US cable industry 
would perhaps be in a better position to agree on something, because they seem 
to be more unified in what they seem to think they want. I can definitely say 
that such unity does not exist at BBF. HGI (Home Gateway Initiative) might have 
been able to do this for the subset of operators that belong to it, but HGI 
says it is closing shop in 2016.

IETF also does not have mandate power, but it does have people who seem to have 
some understanding of the problem and a willingness to work on it. It is also 
the only organization where all parties can easily participate, if they feel so 
inclined. IMO, if IETF can’t make a recommendation, then it just isn’t going to 
happen.

Which isn’t the end of the world.

But I’d like to see IETF try. If IETF picks a solution that retail 
manufacturers are willing to use and that works, is easy to integrate, and does 
not add instability to the firmware, the world will be a better place. If the 
selected solution fails to see widespread adoption, then no harm is done.

If IETF fails to pick anything, then we’ll never know...

You can’t succeed at something if you never even try.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Sander Steffann]

Hi,

> My point was simply that the IETF has multiple of … pretty much everything 
> else … the reason why things work is that somebody (an operator group, an 
> industry alliance/forum, …) figure out what is MTI — for their context — and 
> then do that.
> 
> I am simply wondering out loud why that would not, also, work here? 

Because a homenet doesn't have an operator, let alone an operator group or 
alliance. For managed networks the operator can decide what protocol to use. 
For unmanaged networks that have to work for people who don't have any clue 
about networking there is nobody to make that choice: it just has to work.

And if we leave it to CPE vendor alliances the chance of getting them all to 
implement the same protocol are pretty bad. I don't want to end up in a 
situation where products have to be labelled with Homenet-BABEL® and/or 
Homenet-ISIS® logo's etc... And then we'll need products that support multiple 
protocols, and then we need redistribution between those protocols, and then we 
end up in a nightmare situation where weird routing loops happen, the homenet 
breaks for unknown reasons (because there is no operator to solve them) etc etc.

A homenet is supposed to be simple to implement, simple to operate (just plug 
it in), fool-proof etc. All this complexity if very much unwanted and would 
defeat (destroy) the whole homenet effort.

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Ted Lemon]

On Jul 28, 2015, at 11:19 AM, Thomas Clausen  wrote:
> My point was simply that the IETF has multiple of … pretty much everything 
> else … the reason why things work is that somebody (an operator group, an 
> industry alliance/forum, …) figure out what is MTI — for their context — and 
> then do that.

It is entirely appropriate for this to be done, and indeed I think it would 
address Mikael’s use case a lot better than getting homenet to change its 
charter to support what Mikael wants to deploy.

However, what homenet is chartered to specify is a suite of standards that, if 
a router vendor ships them, will allow that router to interoperate with other 
routers that also conform to the same suite of standards, even if the two 
vendors have no association other than that they both read the same RFCs.   
This is something that the IETF does, and is good at, and is appropriate for 
homenet to do, and is what homenet is chartered to do.

In _that_ context, an MTI routing protocol is required, or else such routers 
will not be able to interoperate.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Thomas Clausen]

Dear Ted,

My point was simply that the IETF has multiple of … pretty much everything else 
… the reason why things work is that somebody (an operator group, an industry 
alliance/forum, …) figure out what is MTI — for their context — and then do 
that.

I am simply wondering out loud why that would not, also, work here? 

Best,

Thomas

> On Jul 28, 2015, at 17:08, Ted Lemon  wrote:
> 
> On Jul 28, 2015, at 9:09 AM, Thomas Clausen  > wrote:
>>  4/  I am not so sure that HOMENET (or the IETF) wins by staging a 
>>  beauty contest among routing protocols, to “pick the most 
>> beautiful”,
>>  and then mandate that as:
>> 
>>  “THE ONE TRUE HOMENET ROUTING PROTOCOL”.
>> 
>>  It seems that the collateral damage from this is non-trivial, 
>> in terms of
>>  time expanded on precisely not getting anywhere on this issue, 
>> arguing 
>>  instead of progressing.
> 
> Some routing protocol has to be MTI, or else you get boxes from different 
> vendors that, when plugged together, fail to interoperate.   If it were not 
> for this unfortunate truth, we could indeed simply blow off the question of 
> choosing an MTI protocol for the homenet.
> 
> As to Richard’s point about LLNs, Pascal brought up ROLL as a possibility for 
> the homenet and it was considered by the design team, which did not conclude 
> that it was a viable alternative.   This didn’t come up in the discussion, so 
> I don’t know why they didn’t, but it isn’t the cast that it wasn’t considered.
> 
> And as for why LLNs need to be stub networks, it’s so that we don’t 
> accidentally try to use them as transit networks, not because they are 
> second-class citizens or not considered important by homenet.   I certainly 
> consider them quite important, and do not want my LLN devices’ batteries run 
> down providing transit for Netflix.
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Ted Lemon]

On Jul 28, 2015, at 9:09 AM, Thomas Clausen  wrote:
>   4/  I am not so sure that HOMENET (or the IETF) wins by staging a 
>   beauty contest among routing protocols, to “pick the most 
> beautiful”,
>   and then mandate that as:
> 
>   “THE ONE TRUE HOMENET ROUTING PROTOCOL”.
> 
>   It seems that the collateral damage from this is non-trivial, 
> in terms of
>   time expanded on precisely not getting anywhere on this issue, 
> arguing 
>   instead of progressing.

Some routing protocol has to be MTI, or else you get boxes from different 
vendors that, when plugged together, fail to interoperate.   If it were not for 
this unfortunate truth, we could indeed simply blow off the question of 
choosing an MTI protocol for the homenet.

As to Richard’s point about LLNs, Pascal brought up ROLL as a possibility for 
the homenet and it was considered by the design team, which did not conclude 
that it was a viable alternative.   This didn’t come up in the discussion, so I 
don’t know why they didn’t, but it isn’t the cast that it wasn’t considered.

And as for why LLNs need to be stub networks, it’s so that we don’t 
accidentally try to use them as transit networks, not because they are 
second-class citizens or not considered important by homenet.   I certainly 
consider them quite important, and do not want my LLN devices’ batteries run 
down providing transit for Netflix.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Thomas Clausen]

I was going to stay quiet on this issue, but what the heck…I’ve been following 
this on the sidelines for long enough to think I have an opinion (without 
having a stake in this).

My immediate impulse, from following all this from the peanut gallery, is that:

1/  It is required that HOMENET provides the protocols necessary 
for 
the “homenet specific” (configuration, …) stuff — prefix 
assignment, 
DNCP, HNCP seem to be doing that.

2/  It is required that the “homenet specific” stuff is routing 
protocol 
agnostic, and specifies an interface to the routing protocol 
(for example
“thou shalt support src-dest routing”), which also seems to be 
the case.

3/  It is fine that HOMENET is doing due diligence and verifying 
that/if 
IETF sanctioned routing protocols exist that satisfy the 
requirements 
— it seems that that’s the case, in no small part due to the 
many 
implementations and demos we’ve seen (which is awesome), from 
commercial vendors (awesome), open-source guys (awesome, also), 
and commercial-vendors-doing-open-source (which is awesome, 
too).

4/  I am not so sure that HOMENET (or the IETF) wins by staging a 
beauty contest among routing protocols, to “pick the most 
beautiful”,
and then mandate that as:

“THE ONE TRUE HOMENET ROUTING PROTOCOL”.

It seems that the collateral damage from this is non-trivial, 
in terms of
time expanded on precisely not getting anywhere on this issue, 
arguing 
instead of progressing.

5/  That brings me to the point of this email …

Figuring out “what goes in the box sold to consumers”, is that 
really an
IETF issue? The IETF provides the standardized building blocks, 
following
a large consensus process — then an industry alliance runs off, 
with the
actual stakeholders as members, and figure out which from among 
those
building blocks to use, and how to put them together (ZigbeeIP 
comes 
to mind, as a recent example of such, and that because I am 
replying to 
Robert here … ) 

IMO, homenet is doing fairly well on 1, 2, and  3. 

It seems that when trying to do 5, nuclear meltdown ensures. Maybe that’s just 
an indication that 5 is, indeed, better done in a different context?  I seem to 
recall that it *used* to be “let the market figure out which XXX it wants”, for 
whatever value of XXX — why would this have to be any different?

Best,

Thomas

PS: Yes, those who know me will know that I would likely have actual routing 
protocol preferences. I’m not a stakeholder in this work, so I’m keeping those 
preferences to myself.

PS2: And yes, precisely as I am not a stakeholder in this, you’re free to 
ignore me — or to consider this a slightly more outside view (your call).


> On Jul 28, 2015, at 11:36, Robert Cragie  wrote:
> 
> +1 - well said. If it weren't actually a serious issue, I would find the 
> constant bickering in homenet re. routing protocol quite comical. I come from 
> the other end of the spectrum (LLNs) and was put off a while ago with the 
> general disdain for catering for anything "the light switch guys" (as we were 
> called, I believe) would like to have in a homenet, As a result, we ended up 
> as a "stub network".
> 
> I don't have a horse in the race but I have to agree with the general 
> sentiment that it makes sense to pick a single routing protocol which was 
> actually designed to cater for all types of links. Shoehorning this 
> capability into an existing protocol may be possible but I completely agree 
> with what Ted says - this now becomes effectively a new routing protocol and 
> a research project.
> 
> Robert
> 
> On 28 July 2015 at 09:38, Gert Doering  > wrote:
> Hi,
> 
> On Mon, Jul 27, 2015 at 10:55:52PM +, Hemant Singh (shemant) wrote:
> > Thanks.   Seeing other replies, I also hear a requirement (d) have 
> > plug-and-play routing, and (e) support MIF.   I think plug-and-play is a 
> > work in progress until routing is decided.  I would break down the problem 
> > by using Babel on the wifi links and IS-IS on the wired link - what do 
> > folks think?
> 
> This is a totally idiotic idea.
> 
> Sorry to be so blunt, but there is NOTHING to be gained by insisting on
> "we must use IS-IS somewhere! we'll look long and hard to find a niche
> where it works, and hammer it in there!".
> 
> Running two different routing protocols in the *homenet* means "totally
> not understanding what homenet is about".  This is not a managed environment,
> with Big Name Router Vendors and Big Brains Routing Code Guys creating
> products, but *HOME*.  With CPE vendors involved.
> 
> Gert Doering
> 

Re: [homenet] Moving forward.

[Robert Cragie]

+1 - well said. If it weren't actually a serious issue, I would find the
constant bickering in homenet re. routing protocol quite comical. I come
from the other end of the spectrum (LLNs) and was put off a while ago with
the general disdain for catering for anything "the light switch guys" (as
we were called, I believe) would like to have in a homenet, As a result, we
ended up as a "stub network".

I don't have a horse in the race but I have to agree with the general
sentiment that it makes sense to pick a single routing protocol which was
actually designed to cater for all types of links. Shoehorning this
capability into an existing protocol may be possible but I completely agree
with what Ted says - this now becomes effectively a new routing protocol
and a research project.

Robert

On 28 July 2015 at 09:38, Gert Doering  wrote:

> Hi,
>
> On Mon, Jul 27, 2015 at 10:55:52PM +, Hemant Singh (shemant) wrote:
> > Thanks.   Seeing other replies, I also hear a requirement (d) have
> plug-and-play routing, and (e) support MIF.   I think plug-and-play is a
> work in progress until routing is decided.  I would break down the problem
> by using Babel on the wifi links and IS-IS on the wired link - what do
> folks think?
>
> This is a totally idiotic idea.
>
> Sorry to be so blunt, but there is NOTHING to be gained by insisting on
> "we must use IS-IS somewhere! we'll look long and hard to find a niche
> where it works, and hammer it in there!".
>
> Running two different routing protocols in the *homenet* means "totally
> not understanding what homenet is about".  This is not a managed
> environment,
> with Big Name Router Vendors and Big Brains Routing Code Guys creating
> products, but *HOME*.  With CPE vendors involved.
>
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AGVorstand: 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
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Juliusz Chroboczek]

>> I may have misunderstood -- but are you saying that you have the
>> technology to perform bidirectional redistribution between two very
>> different routing protocols in an unadministered network, and
>> guarantee the absence of persistent routing loops without making
>> any assumptions about the topology?

> Have you run, say, RIPng, on one network interface facing the
> interior of a network while running IS-IS on another interface on
> the same router?

Yes, I have.  On one router this is easy.  You obviously need two
routers in order to create a loop.

> Once each routing is configured and redistributing routes between,
> what is the issue?

First Google hit for "redistribution persistent loop cisco" [1]:

  "If you misconfigured Route Redistribution, this will lead to
   sub-optimal routing and even severe instabilities such as route
   oscillations and persistent routing loops.

   [...]

   To avoid routing loops, a route received from a routing instance
   must not be re-injected back into the same instance."

In short, you must configure your redistribution filters to ensure
that there isn't a redistribution loop.  While that's in principle
possible in a managed network (but error-prone and fragile), it's
suicide in an unmanaged network.

Hemant, the fact that general redistribution is impossible in
unmanaged networks is the very reason for the existence of Babel,
a single protocol that is reasonably efficient on both on your
favourite gigabit technology and on the unstable, non-transitive,
lossy bits that people will include in their networks, whether Mikael
likes it or not.  If redistribution were as easy as you make it, you'd
just run IS-IS on the wired bits and OLSRv2 on the meshy bits, both of
which are fine protocols in their particular area of application.

[1] 
https://supportforums.cisco.com/document/12015996/route-redistribution-explained

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Gert Doering]

Hi,

On Mon, Jul 27, 2015 at 10:55:52PM +, Hemant Singh (shemant) wrote:
> Thanks.   Seeing other replies, I also hear a requirement (d) have 
> plug-and-play routing, and (e) support MIF.   I think plug-and-play is a work 
> in progress until routing is decided.  I would break down the problem by 
> using Babel on the wifi links and IS-IS on the wired link - what do folks 
> think?  

This is a totally idiotic idea.

Sorry to be so blunt, but there is NOTHING to be gained by insisting on
"we must use IS-IS somewhere! we'll look long and hard to find a niche
where it works, and hammer it in there!".

Running two different routing protocols in the *homenet* means "totally
not understanding what homenet is about".  This is not a managed environment,
with Big Name Router Vendors and Big Brains Routing Code Guys creating
products, but *HOME*.  With CPE vendors involved.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgpkbCDeTIUuJ.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Dave Taht]

I would like to *require* of the "design team" that they actually
install the available software on at least three routers and try it.

I would certainly like to require of the working group the same, but
despite 2 years of trying, have lost hope.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Tore Anderson]

* "Hemant Singh (shemant)" 

> (c) An average home has one wifi link.

I think you'll find that an "average" home has more than 1 wifi link.
Maybe somewhere between 1 and 2 is the correct number.

For example: The concrete between the two floors in my apartment makes
an AP located upstairs practically unusable from downstairs and vice
versa. So I have two bridging APs that share the same ESSID and are
connected to the same wired layer-2 segment. That works well enough.

Tore

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Hemant Singh (shemant)]

-Original Message-
From: Juliusz Chroboczek [mailto:j...@pps.univ-paris-diderot.fr] 
Sent: Monday, July 27, 2015 7:45 PM
To: Hemant Singh (shemant)
Cc: HOMENET
Subject: Re: [homenet] Moving forward.

>I may have misunderstood -- but are you saying that you have the technology to 
>perform bidirectional redistribution between two very different routing 
>protocols in an unadministered network, and >guarantee the absence of 
>persistent routing loops without making any assumptions about the topology?

>If so, I would humbly request a pointer to this extremely cool technology.

Have you run, say, RIPng, on one network interface facing the interior of a 
network while running IS-IS on another interface on the same router?  Once each 
routing is configured and redistributing routes between, what is the issue?  
The prefixes between each routing are disjoint.

Hemant

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Juliusz Chroboczek]

> I would break down the problem by using Babel on the wifi links and
> IS-IS on the wired link - what do folks think?  If each of Babel and
> IS-IS are auto-configurable or close to it, the two combined can be
> auto-configurable as well.  They each have to distribute their
> static and connected routes to each other and such a distribution
> can totally be automated.

I may have misunderstood -- but are you saying that you have the
technology to perform bidirectional redistribution between two very
different routing protocols in an unadministered network, and
guarantee the absence of persistent routing loops without making any
assumptions about the topology?

If so, I would humbly request a pointer to this extremely cool technology.

-- Juliusz (humbled)

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Hemant Singh (shemant)]

Pierre,

Thanks.   Seeing other replies, I also hear a requirement (d) have 
plug-and-play routing, and (e) support MIF.   I think plug-and-play is a work 
in progress until routing is decided.  I would break down the problem by using 
Babel on the wifi links and IS-IS on the wired link - what do folks think?  If 
each of Babel and IS-IS are auto-configurable or close to it, the two combined 
can be auto-configurable as well.  They each have to distribute their static 
and connected routes to each other and such a distribution can totally be 
automated. 

Thanks,

Hemant   

-Original Message-
From: Pierre Pfister [mailto:pie...@darou.fr] 
Sent: Monday, July 27, 2015 2:34 PM
To: Hemant Singh (shemant)
Cc: Pascal Thubert (pthubert); Ted Lemon; HOMENET; Terry Manderson; Gert 
Doering; Dino Farinacci; Mikael Abrahamsson
Subject: Re: [homenet] Moving forward.


I just spent one hour at my sister’s home trying to optimize the positioning of 
a WiFi repeater.
Her home is definitely an average-sized one, with average people living in it 
that do not know anything about IP networking.
But they have an ethernet link, a PLC link because the ISP told them to use it, 
and a dummy wifi repeater which does some black magic to extend the wifi 
network without requiring more configuration.

So I’d say:
(c) A home network may have multiple wifi links. Some of which may be used for 
transit.

- Pierre
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Pierre Pfister]

> 
> (c) An average home has one wifi link.
> 

I just spent one hour at my sister’s home trying to optimize the positioning of 
a WiFi repeater.
Her home is definitely an average-sized one, with average people living in it 
that do not know anything about IP networking.
But they have an ethernet link, a PLC link because the ISP told them to use it, 
and a dummy wifi repeater
which does some black magic to extend the wifi network without requiring more 
configuration.

So I’d say:
(c) A home network may have multiple wifi links. Some of which may be used for 
transit.

- Pierre
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Ted Lemon]

On Jul 27, 2015, at 8:04 AM, Hemant Singh (shemant)  wrote:
> (a) A routing protocol to use on the wired link at home  

No.   There are multiple links, some wired, some wireless.   The whole point of 
homenet is to get past “the link” or “the wired link and the wireless link”.   
If we just wanted to handle “the link,” we already have an RFC that adequately 
addresses that use case.

> (b) Whatever routing is used on the wired link should also support the lossy 
> wifi link in the home.  

No.   There may be wifi links in the home used as transit links, and those have 
to work even if propagation is not 99.999%.

> (c) An average home has one wifi link.

No.

> Based on the requirements above, I would use ISIS for (a) and configure a 
> static route to the wifi link to deal with (b).


And you would have failed to address the problem that that homenet set out to 
solve.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Hemant Singh (shemant)]

-Original Message-
From: Margaret Cullen [mailto:mrculle...@gmail.com] On Behalf Of Margaret Cullen
Sent: Monday, July 27, 2015 8:08 AM
To: Hemant Singh (shemant)
Cc: Pascal Thubert (pthubert); Ted Lemon; HOMENET; Terry Manderson; Gert 
Doering; Dino Farinacci; Mikael Abrahamsson
Subject: Re: [homenet] Moving forward.


>This depends on what you mean by "one wifi link".  I think we expect homes to 
>continue to have guest and home wi-fi SSIDs, or equivalent.  I don't know 
>whether this will >continue to be provided at layer 2, or whether homenet 
>prefix delegation would allow these links to be routed, instead of bridged.  
>Also, I think we expect homes to potentially >have other types of wireless 
>links (i.e. IEEE 802.16).

One SSID.  I agree two SSIDs are also possible and so is 802.16.  So now one 
has several wireless links which are lossy.

Thanks,

Hemant


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Juliusz Chroboczek]

> (c) An average home has one wifi link.

Many home routers have three wireless links (2.4GHz, 5GHz, and guest).
This will only get more common with 802.11ac.

> Any other requirements or changes to the above text?

Many would prefer a routing protocol with a well-defined, self-contained
specification that can be implemented in finite time.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Henning Rogge]

Hi,

there is also the point that "wifi repeaters" are quite stupid devices at
the moment.

I could see "Homenet wifi extenders" which just are Homenet routers with
multiple wifi interfaces routing traffic between them.

Henning Rogge

On Mon, Jul 27, 2015 at 2:12 PM, Jonathan Hansford 
wrote:

> Was in the process of asking the same question about "one wifi link". I
> don't think my homenet is "average", but I have the wifi router and two
> APs,
> each has its own SSID for static devices, and share one home SSID and one
> Guest SSID for more mobile devices.
>
> Jonathan
>
> > -Original Message-
> > From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Margaret
> > Cullen
> > Sent: 27 July 2015 13:08
> > To: Hemant Singh (shemant) 
> > Cc: Pascal Thubert (pthubert) ; Ted Lemon
> > ; Dino Farinacci ; HOMENET
> > ; Mikael Abrahamsson ; Gert
> > Doering ; Terry Manderson 
> > Subject: Re: [homenet] Moving forward.
> >
> >
> > On Jul 27, 2015, at 8:04 AM, "Hemant Singh (shemant)"
> >  wrote:
> > > (c) An average home has one wifi link.
> > >
> > > Any other requirements or changes to the above text?
> >
> > This depends on what you mean by "one wifi link".  I think we expect
> homes
> > to continue to have guest and home wi-fi SSIDs, or equivalent.  I don't
> know
> > whether this will continue to be provided at layer 2, or whether homenet
> > prefix delegation would allow these links to be routed, instead of
> bridged.
> > Also, I think we expect homes to potentially have other types of wireless
> > links (i.e. IEEE 802.16).
> >
> > Margaret
> >
> >
> > ___
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Jonathan Hansford]

Was in the process of asking the same question about "one wifi link". I
don't think my homenet is "average", but I have the wifi router and two APs,
each has its own SSID for static devices, and share one home SSID and one
Guest SSID for more mobile devices.

Jonathan

> -Original Message-
> From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Margaret
> Cullen
> Sent: 27 July 2015 13:08
> To: Hemant Singh (shemant) 
> Cc: Pascal Thubert (pthubert) ; Ted Lemon
> ; Dino Farinacci ; HOMENET
> ; Mikael Abrahamsson ; Gert
> Doering ; Terry Manderson 
> Subject: Re: [homenet] Moving forward.
> 
> 
> On Jul 27, 2015, at 8:04 AM, "Hemant Singh (shemant)"
>  wrote:
> > (c) An average home has one wifi link.
> >
> > Any other requirements or changes to the above text?
> 
> This depends on what you mean by "one wifi link".  I think we expect homes
> to continue to have guest and home wi-fi SSIDs, or equivalent.  I don't
know
> whether this will continue to be provided at layer 2, or whether homenet
> prefix delegation would allow these links to be routed, instead of
bridged.
> Also, I think we expect homes to potentially have other types of wireless
> links (i.e. IEEE 802.16).
> 
> Margaret
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Gert Doering]

Hi,

On Mon, Jul 27, 2015 at 12:04:28PM +, Hemant Singh (shemant) wrote:
> Based on the requirements above, I would use ISIS for (a) and configure a 
> static route to the wifi link to deal with (b).

"If all you have is a hammer, every problem looks like a nail"

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgp06enY_mTdc.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Margaret Cullen]

On Jul 27, 2015, at 8:04 AM, "Hemant Singh (shemant)"  wrote:
> (c) An average home has one wifi link.
> 
> Any other requirements or changes to the above text?

This depends on what you mean by "one wifi link".  I think we expect homes to 
continue to have guest and home wi-fi SSIDs, or equivalent.  I don't know 
whether this will continue to be provided at layer 2, or whether homenet prefix 
delegation would allow these links to be routed, instead of bridged.  Also, I 
think we expect homes to potentially have other types of wireless links (i.e. 
IEEE 802.16).

Margaret


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Hemant Singh (shemant)]

I agree with Pascal.   Thrashing for few years is not good.   Just publish a 
short document for what the homenet routing requirements are and then let the 
IETF routing WG look into the issue. 

So far, having worked with Ted privately, I see the requirements are:

(a) A routing protocol to use on the wired link at home  
(b) Whatever routing is used on the wired link should also support the lossy 
wifi link in the home.  
(c) An average home has one wifi link.

Any other requirements or changes to the above text?

Based on the requirements above, I would use ISIS for (a) and configure a 
static route to the wifi link to deal with (b).

Hemant

-Original Message-
From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Pascal Thubert 
(pthubert)
Sent: Sunday, July 26, 2015 3:18 PM
To: Ted Lemon
Cc: HOMENET; Mikael Abrahamsson; Gert Doering; Dino Farinacci; Terry Manderson
Subject: Re: [homenet] Moving forward.

Hello Ted:

Seems that there's more work than what we can expect from a DT. Otherwise we'd 
be all set by now.

What about forming a flash WG in routing area to see if:

- we can extract requirements for home
- there's such a thing as a one size fits all homes routing protocol
- provide recommendations on how to use (a combination of) existing standards, 
and, if that can not be done,whether a new protocol is needed

ROLL followed that path.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Henning Rogge]

On Mon, Jul 27, 2015 at 11:59 AM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:

> Whatever happens within Homenet, it's good to hear that we've managed to
> put dynamically computed, unstable metrics on the radar for at least some
> IETF insiders.
>
> The exchange of ideas is also happening in the other direction -- Matthieu
> and I are going to Battlemesh next week, and we'll be trying to sell the
> idea of source-specific routing to the community mesh people.  (Henning
> is telling me that he already has an implementation of source-specific
> routing for OLSRv2, he'll hopefully demo it at Battlemesh.)


The code itself is working (I tested it with Teco Boot during the IETF), I
just have to resolve the detection of routers that cannot do
source-specific routing.

Henning Rogge
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Juliusz Chroboczek]

> yes, sure, IS-IS is great. It does a lot. It would almost certainly work
> very nicely in homenet. However, it lacks a feature that the working group
> agreed we needed: support for wireless transit networks that might be
> lossy. This feature could be added, but is not yet present.

Whatever happens within Homenet, it's good to hear that we've managed to
put dynamically computed, unstable metrics on the radar for at least some
IETF insiders.

The exchange of ideas is also happening in the other direction -- Matthieu
and I are going to Battlemesh next week, and we'll be trying to sell the
idea of source-specific routing to the community mesh people.  (Henning
is telling me that he already has an implementation of source-specific
routing for OLSRv2, he'll hopefully demo it at Battlemesh.)

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Gert Doering]

Hi,

On Sun, Jul 26, 2015 at 07:18:14PM +, Pascal Thubert (pthubert) wrote:
> What about forming a flash WG in routing area to see if:
[..]

I really wonder if this is is about "getting anywhere" any longer, or 
whether we should just form a few subcommittees that decide on task forces
to establish temporary WGs to decide on the proper naming of some other
working group drafts instead.

I've done testing with babels-based openwrt HNCP implementation over a year
ago(!), and while that code had warts, it actually worked well for my tests.

Instead on just agreeing on "working code is good, let's write it up!" this
working group is now even further away from actually agreeing on anything
that could lead to a shipping product based on an actual *standard*...

So, folks, what is that you *want*?   "See your favourite routing protocol
win, no matter what the cost" or "produce something that can be implemented
by a chinese garage shop (... by taking one of the two existing and well-
tested open source implementations, slapping a new label on it, and shipping 
it)"?

Gert Doering
-- Operator
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgplpEpdcukXX.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Ray Bellis]

On 26/07/2015 16:10, Ted Lemon wrote:

Based on the experience with the DT, it’s clear that some of the points that 
are made in the homenet architecture document were not sufficiently clear.   
However, all of these points have been discussed by the working group over the 
past four years, and the lack of clarity in the document is not the result of a 
lack of clarity on the part of the working group; indeed, probably just the 
opposite.


Ted - thanks.

Some will recall that some things were intentionally left out of RFC 
7368 precisely because being more specific would have prejudiced any 
future protocol selection.


That's why RFC 7368 was silent on the specifics of whether we use 
routing metrics (and thereby implicitly favouring link state over 
distance vector or vice versa) but just says that the system should be 
able to cope with links of varying qualities.  The document is generally 
more interested in the end results, rather than the means.


As Terry announced, the DT will now produce an I-D that will seek to 
document the current working group consensus on our routing requirements 
so that an informed decision can be made.


Please, let's work on *constructive* feedback towards that goal, and in 
the meantime make good progress on our remaining working group items.


thanks,

Ray

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Pascal Thubert (pthubert)]

Hello Ted:

Seems that there's more work than what we can expect from a DT. Otherwise we'd 
be all set by now.

What about forming a flash WG in routing area to see if:

- we can extract requirements for home
- there's such a thing as a one size fits all homes routing protocol
- provide recommendations on how to use (a combination of) existing standards, 
and, if that can not be done,whether a new protocol is needed

ROLL followed that path.

Take care,

Pascal

> Le 26 juil. 2015 à 17:10, Ted Lemon  a écrit :
> 
>> On Jul 26, 2015, at 10:36 AM, Dino Farinacci  wrote:
>> And what makes you think I do not understand the context?
>> I attended last Homenet WG in Dallas and then joined the list. So I've been 
>> reading the list for 3 months and catching up on all documents.
> 
> Then you probably remember just how unhelpful and un-illuminating the 
> discussion at the microphone was in Dallas.   This working group has been 
> discussing the routing protocol problem for several years, and at this point 
> there seems to be very little constructive discussion going on, so it is 
> unfortunately not surprising that despite having participated for the last 
> three months, you do not know why the working group can’t reach consensus to 
> just use IS-IS.
> 
> Based on the experience with the DT, it’s clear that some of the points that 
> are made in the homenet architecture document were not sufficiently clear.   
> However, all of these points have been discussed by the working group over 
> the past four years, and the lack of clarity in the document is not the 
> result of a lack of clarity on the part of the working group; indeed, 
> probably just the opposite.
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Ted Lemon]

On Jul 26, 2015, at 10:36 AM, Dino Farinacci  wrote:
> And what makes you think I do not understand the context?
> I attended last Homenet WG in Dallas and then joined the list. So I've been 
> reading the list for 3 months and catching up on all documents. 

Then you probably remember just how unhelpful and un-illuminating the 
discussion at the microphone was in Dallas.   This working group has been 
discussing the routing protocol problem for several years, and at this point 
there seems to be very little constructive discussion going on, so it is 
unfortunately not surprising that despite having participated for the last 
three months, you do not know why the working group can’t reach consensus to 
just use IS-IS.

Based on the experience with the DT, it’s clear that some of the points that 
are made in the homenet architecture document were not sufficiently clear.   
However, all of these points have been discussed by the working group over the 
past four years, and the lack of clarity in the document is not the result of a 
lack of clarity on the part of the working group; indeed, probably just the 
opposite.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Dino Farinacci]

And what makes you think I do not understand the context?

I attended last Homenet WG in Dallas and then joined the list. So I've been 
reading the list for 3 months and catching up on all documents. 

Dino

> On Jul 26, 2015, at 4:13 PM, Ted Lemon  wrote:
> 
>> On Jul 26, 2015, at 2:46 AM, Dino Farinacci  wrote:
>> The email wasn't intended to be, honest. I was trying to be helpful. And as 
>> I said ignore my email if you wish to. 
> 
> I appreciate that, but the essence of being helpful is to start out by trying 
> to clearly understand the context.   You didn’t do anything wrong—it’s just 
> that we’ve had about a dozen routing experts come through, not spend the time 
> truly understanding the context, and then express confidence that IS-IS, OSPF 
> or some other routing standard that they like solves our problem perfectly.   
> We cannot resolve this problem people don't listen to our reasons for not 
> having consensus to use $random_routing_protocol.   So I used your 
> well-intentioned comment as a foil for making that point.
> 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Ted Lemon]

On Jul 26, 2015, at 2:46 AM, Dino Farinacci  wrote:
> The email wasn't intended to be, honest. I was trying to be helpful. And as I 
> said ignore my email if you wish to. 

I appreciate that, but the essence of being helpful is to start out by trying 
to clearly understand the context.   You didn’t do anything wrong—it’s just 
that we’ve had about a dozen routing experts come through, not spend the time 
truly understanding the context, and then express confidence that IS-IS, OSPF 
or some other routing standard that they like solves our problem perfectly.   
We cannot resolve this problem people don't listen to our reasons for not 
having consensus to use $random_routing_protocol.   So I used your 
well-intentioned comment as a foil for making that point.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Sander Steffann]

Hi,

> Op 26 jul. 2015, om 03:07 heeft Ted Lemon  het volgende 
> geschreven:
> 
> Thanks, but the working group is not confused as to whether IS-IS could be 
> made to work.   We understand that it could be made to work.   One active 
> participant in the working group has an open source implementation.   It 
> works.   It lacks a feature we want, but that feature could be added.   
> However, adding that feature would be a new research project, which would 
> require a substantial game of catch-up.   That is why there is a controversy 
> about this in the working group.   Otherwise I would be wholeheartedly 
> supporting IS-IS—I fought against the consideration of Babel back when it 
> first came up, on the grounds that we already had good candidates, and have 
> no personal stake in its winning other than that I now think it would get us 
> across the finish line faster, if we were allowed to use it.

I think this is a good summary. We seem to have something that works well for 
what we need. I am sure we can come up with something even better, but at some 
point we need to realise that good enough is good enough. As an ISP I want to 
reach the point where I can actually deliver homenet-capable products to my 
customers.

Cheers,
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Dino Farinacci]

> This whole thread is really patronizing.

The email wasn't intended to be, honest. I was trying to be helpful. And as I 
said ignore my email if you wish to. 

Dino
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Ted Lemon]

On Jul 25, 2015, at 8:56 PM, Hemant Singh (shemant)  wrote:
> One comment that ISIS does not need an IP address to work is not very 
> important for IPv6.   An IPv6 node creates its link-local address and thus 
> has an IPv6 address, by default.  The link local address can be used in by 
> any routing protocol.  A global IPv6 address can also be auto-configured for 
> the IPv6 node using SLAAC.

Thanks, but the working group is not confused as to whether IS-IS could be made 
to work.   We understand that it could be made to work.   One active 
participant in the working group has an open source implementation.   It works. 
  It lacks a feature we want, but that feature could be added.   However, 
adding that feature would be a new research project, which would require a 
substantial game of catch-up.   That is why there is a controversy about this 
in the working group.   Otherwise I would be wholeheartedly supporting IS-IS—I 
fought against the consideration of Babel back when it first came up, on the 
grounds that we already had good candidates, and have no personal stake in its 
winning other than that I now think it would get us across the finish line 
faster, if we were allowed to use it.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Hemant Singh (shemant)]

Ted,

Thanks for the clarifying two emails.  I agree, a home router protocol should 
include good quality open-software.   Let’s have hackthons at each IETF for a 
few future ones and get open-source ISIS up to deployable quality if anyone 
would like to use it.

One comment that ISIS does not need an IP address to work is not very important 
for IPv6.   An IPv6 node creates its link-local address and thus has an IPv6 
address, by default.  The link local address can be used in by any routing 
protocol.  A global IPv6 address can also be auto-configured for the IPv6 node 
using SLAAC.

Hemant


From: Ted Lemon [mailto:mel...@fugue.com]
Sent: Saturday, July 25, 2015 8:43 PM
To: Hemant Singh (shemant)
Cc: Gert Doering; Mikael Abrahamsson; HOMENET; Terry Manderson
Subject: Re: [homenet] Moving forward.

On Jul 25, 2015, at 4:50 PM, Hemant Singh (shemant) 
mailto:shem...@cisco.com>> wrote:
Even the switching networks use ISIS because TRILL (rfc6325) uses ISIS beneath 
the covers.  At least three switch chip vendors support TRILL and thus ISIS.

Homenet is chartered to produce a suite of specifications that will allow for 
autonomous unmanaged routing in a home network.   The set of vendor 
organizations that support TRILL is, AFAIK, completely disjoint from the set of 
vendor organizations that sell routers for the home.   I would be delighted if 
we could get home routers from some of the rather excellent vendor 
organizations in the first set, but that is not the reality at the moment, and 
I see no reason to expect that to change.

Furthermore, we really need for this to be supported by open source router 
software, and AFAIK TRILL is not supported on that software, although certainly 
in principle it could be, and David Lamparter’s open source IS-IS 
implementation for OpenWRT might even be able to be turned to that purpose if 
someone were interested.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Ted Lemon]

On Jul 25, 2015, at 4:50 PM, Hemant Singh (shemant)  wrote:
> Even the switching networks use ISIS because TRILL (rfc6325) uses ISIS 
> beneath the covers.  At least three switch chip vendors support TRILL and 
> thus ISIS.  

Homenet is chartered to produce a suite of specifications that will allow for 
autonomous unmanaged routing in a home network.   The set of vendor 
organizations that support TRILL is, AFAIK, completely disjoint from the set of 
vendor organizations that sell routers for the home.   I would be delighted if 
we could get home routers from some of the rather excellent vendor 
organizations in the first set, but that is not the reality at the moment, and 
I see no reason to expect that to change.

Furthermore, we really need for this to be supported by open source router 
software, and AFAIK TRILL is not supported on that software, although certainly 
in principle it could be, and David Lamparter’s open source IS-IS 
implementation for OpenWRT might even be able to be turned to that purpose if 
someone were interested.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Ted Lemon]

On Jul 25, 2015, at 4:24 PM, Dino Farinacci  wrote:
> Correction. It took about 2 years to get it right and 18 years of usage and 
> new features additions (like IPv6 about 15 years ago). But most features the 
> homenet use-case may not need to use. 

This whole thread is really patronizing.   Sorry, Dino.   The problem is that 
yes, sure, IS-IS is great.   It does a lot.   It would almost certainly work 
very nicely in homenet.   However, it lacks a feature that the working group 
agreed we needed: support for wireless transit networks that might be lossy.   
This feature could be added, but is not yet present.   Babel has been 
extensively tested in environments where wireless transit networks with decent 
but not perfect propagation characteristics are in use, and it does really well 
there.

So reassuring us that IS-IS is a great routing protocol is entirely beside the 
point.   That isn’t why this controversy exists.   Before I heard about Babel, 
I wanted OSPF, because we had a working implementation, and didn’t want IS-IS, 
because we didn’t have a working implementation.   The sales pitch for Babel 
was quite convincing, and managed to sway most of the working group.   One of 
the big problems we have had in the working group is people coming in from 
outside second-guessing our reasons for wanting Babel who haven’t participated 
in the conversation and just assume that there is no benefit to using Babel 
instead of IS-IS, and assume that the problem is just that nobody has made a 
clear argument yet in favor of IS-IS.

There are also a few people participating in homenet who actually want a 
different thing than homenet was chartered to produce, and who are proponents 
of IS-IS in the working group.   What they want is reasonable, but if we 
produced that thing, we would not have addressed our charter.

That said, at this point I would rather that we make a decision than keep 
arguing about it, even if the decision is to use IS-IS.   But it’s a bit 
painful to keep hearing yet another smart person who doesn’t really grok what 
homenet is trying to do come in and tell us IS-IS is a good routing protocol, 
as if this were an astonishing piece of new information we hadn’t previously 
had.  It’s quite clear to me that IS-IS is not the best choice for the working 
group.   It may be the expedient choice, though.   But if it wins, it will be 
for very much the wrong reason.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Hemant Singh (shemant)]

-Original Message-
From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Gert Doering
Sent: Saturday, July 25, 2015 3:39 PM
To: Mikael Abrahamsson
Cc: HOMENET; Gert Doering; Terry Manderson
Subject: Re: [homenet] Moving forward.

>And that will tell us exactly what about the newly written ISIS 
>implementations that would be used in a homenet environment, written by 
>vendors that have never even *seen* a backbone router in their >life before...?

>What it *does* tell us is that ISIS is a mightily complex protocol that took 
>20+ years to get right for the *best* minds in the routing industry.

Even the switching networks use ISIS because TRILL (rfc6325) uses ISIS beneath 
the covers.  At least three switch chip vendors support TRILL and thus ISIS.  

Hemant

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Jeff Tantsura]

100% agree with Dino - nothing beats extensive use in real networks and 
consecutive bug fixing.
at least you could skip teething...

Regards,
Jeff

On Jul 25, 2015, at 7:10 AM, Dino Farinacci  wrote:

>> Someone needs to put the foot down and choose. Either you choose IETF 
>> process as a tie-breaker, in which case ISIS is the obvious choice, or you 
>> choose some other tie-breaker and then it might be another choice or no 
>> choice.
> 
> Then I’ll be the foot if anyone cares. My 2 cents. You can ignore this email 
> if you want to.
> 
> I have implemented at least once the following protocols dating back to 1985, 
> EGP, ISO-IGRP, OSPF, IS-IS, mBGP, EIGRP (twice), IGMP (twice), MLD, PIM 
> (twice), MSDP (twice) and LISP (twice). So I am speaking from experience. 
> 
> Go with IS-IS. You will not regret it. 
> 
> I implemented IS-IS from the early beginnings of Ross Callon’s RFC 1095, 
> first for Decnet Phase IV and then for Decnet Phase V (OSI). Then we added 
> IPv4 and next IPv6. It has standed the test of time. It can do it for another 
> generation. 
> 
> IS-IS is inherently self discovery, you don’t need to start it with any 
> network address configuration (for any address family including layer-2, if 
> the homenet needs multi-hop layer-2) and more importantly it is 
> self-documenting.
> 
> Dino
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Dino Farinacci]

> What it *does* tell us is that ISIS is a mightily complex protocol that
> took 20+ years to get right for the *best* minds in the routing industry.

Correction. It took about 2 years to get it right and 18 years of usage and new 
features additions (like IPv6 about 15 years ago). But most features the 
homenet use-case may not need to use. 

Dino
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Gert Doering]

Hi,

On Sat, Jul 25, 2015 at 03:21:18PM +0200, Mikael Abrahamsson wrote:
> I have no knowledge that it won't, on the other hand I have more knowledge 
> about interoperating ISIS implementations and its 20+ years of exposure to 
> reality.

And that will tell us exactly what about the newly written ISIS 
implementations that would be used in a homenet environment, written by
vendors that have never even *seen* a backbone router in their life
before...?

What it *does* tell us is that ISIS is a mightily complex protocol that
took 20+ years to get right for the *best* minds in the routing industry.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: 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


pgpYMUnEu_8z3.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Dino Farinacci]

> Someone needs to put the foot down and choose. Either you choose IETF process 
> as a tie-breaker, in which case ISIS is the obvious choice, or you choose 
> some other tie-breaker and then it might be another choice or no choice.

Then I’ll be the foot if anyone cares. My 2 cents. You can ignore this email if 
you want to.

I have implemented at least once the following protocols dating back to 1985, 
EGP, ISO-IGRP, OSPF, IS-IS, mBGP, EIGRP (twice), IGMP (twice), MLD, PIM 
(twice), MSDP (twice) and LISP (twice). So I am speaking from experience. 

Go with IS-IS. You will not regret it. 

I implemented IS-IS from the early beginnings of Ross Callon’s RFC 1095, first 
for Decnet Phase IV and then for Decnet Phase V (OSI). Then we added IPv4 and 
next IPv6. It has standed the test of time. It can do it for another 
generation. 

IS-IS is inherently self discovery, you don’t need to start it with any network 
address configuration (for any address family including layer-2, if the homenet 
needs multi-hop layer-2) and more importantly it is self-documenting.

Dino

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Mikael Abrahamsson]

On Sat, 25 Jul 2015, Juliusz Chroboczek wrote:

Perhaps we could stop caricaturing each other's positions?  I'm sure 
we'll enjoy each other's company much more that way.


I didn't know that was I was doing. I was merely stating the most commonly 
reason I have heard for why babel should be chosen.


I believe that David Lamparter understands this stuff, I suggest you 
speak to him.


Wow. Nice.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Mikael Abrahamsson]

On Sat, 25 Jul 2015, Gert Doering wrote:

What's wrong with picking a routing protocol that will handle both 
unreliable homenet links *and* a perfectly stable topology, in 
preference to a protocol that you seem to imply wants a "stable 
environment"?


Because there are other factors as well, not on the the ones I happened to 
mention.



Babels will work perfectly well on a totally loss-free wired topology.


I have no knowledge that it won't, on the other hand I have more knowledge 
about interoperating ISIS implementations and its 20+ years of exposure to 
reality.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Moving forward.

[Sander Steffann]

Hi,

> What's wrong with picking a routing protocol that will handle both
> unreliable homenet links *and* a perfectly stable topology, in preference
> to a protocol that you seem to imply wants a "stable environment"?
> 
> Babels will work perfectly well on a totally loss-free wired topology.

+1

> [..]
>> One group sees the homenet consisting of a bunch of "ad-hoc" wifi links 
>> with dubious quality and working part of the time, another group sees the 
>> homenet consisting of (fairly) reliable links that can be used for real 
>> time communication and high speed communication that works "all the time". 
>> These visions are not compatible, the requirements that fall out of these 
>> visions are not compatible, and this is why we have this stale-mate.
> 
> We seem to have one routing protocol that handle both variants without
> any drawbacks, and another one which seems to be only suited for one
> variant of homenet.  Why is the decision difficult?

I agree.
Sander

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet