Subject: [homenet] Moving forward.

From: Terry Manderson <[email-masked]>
Date: Fri, 24 Jul 2015 10:22:42 +0000

Dear HOMENET WG,

Apologies if this email reaches your inbox while you are traveling.

I thought it worthwhile to keep you apprised of some immediate action
following the meeting on Wednesday, and a process direction I am going to
follow.

Firstly, I have asked Ray Bellis (HOMENET co-chair) to join the Design
Team (DT) to aid in communicating the HOMENET perspective. I have also
asked
Russ as the DT chair to seek out an additional participant who has deep
and broad expertise in routing.

Secondly, I am asking the DT to seek clarifications from the workgroup on
the routing requirements as highlighted on Wednesday. This will output a
draft that HOMENET might consider adopting as a WG item to improve its
document state and universal understanding.

My drive here is to follow due process in reaching a point where the DT
can, by Yokohama, either:

	- make a defensible recommendation based on the already stated criteria
	or
	- present a summary of why a single selection cannot be made at this time.

While this seems like a delay, I will be speaking with the WG chairs on
the implications.

In the meantime I hope you continue your development work, continually
reflect on the state of code versus specification, and work hard on
interop efforts, and gain more experience.

Thanks
Terry

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 24 Jul 2015 14:11:59 +0200

> This will output a draft that HOMENET might consider adopting as a WG
> item to improve its document state and universal understanding.

Are we agreed that this effort shall not delay the publication of HNCP and
friends?

> In the meantime [...] work hard on interop efforts

Hopefully in the second half of August, failing that early October.

Regards,

-- Juliusz

---

From: Mark Townsley <[email-masked]>
Date: Fri, 24 Jul 2015 14:40:24 -0500

Thank you Terry, Russ, et. al., for agreeing to continue to work on this
with closer participation from folks involved closely in Homenet since day
one by including Ray. I'd suggest including a few open source implementors
as well: David Lampeter, Stephen Barth, and Juliusz all come to mind if any
would be so willing. To get additional operator viewpoint, perhaps Mikael
Abrahamsson, John Brzozowski, and Barbara Stark. You might tap Hans Liu
from D-Link as well. Perhaps even a call to the WG list for willing
contributors.

I would like to echo here something I heard at the microphone on Wednesday:
that the DT deliberations be more transparent, including at least read only
access to the DT mailing list. The plan to produce an internet draft before
Yokohama rather unveiling a powerpoint during the meeting itself is
definitely a step in the right direction as well.

Last but not least, I recall rather strong consensus that the WG not be
hindered by the Routing Protocol Selection debate. As such, I would like
ensure that we can continue to double down on moving forward our existing,
non-routing-protocol, work. Terry, if you have any objection to that,
please let us know now.

Many Thanks,

- Mark

On Fri, Jul 24, 2015 at 5:22 AM, Terry Manderson <[email-masked]>
wrote:

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 24 Jul 2015 22:06:14 +0200 (CEST)

On Fri, 24 Jul 2015, Terry Manderson wrote:

> Secondly, I am asking the DT to seek clarifications from the workgroup 
> on the routing requirements as highlighted on Wednesday. This will 
> output a draft that HOMENET might consider adopting as a WG item to 
> improve its document state and universal understanding.

I doubt we'll get consensus on the requirements for the routing protocol, 
as the babel proponents seem to envision a homenet with really bad wifi 
which needs a protocol such as babel to handle this problem, and others, 
who see a more stable homenet which a linkstate protcol such as ISIS can 
handle just fine.

So as the design team already has discovered and was presented in the 
meeting, there is no consensus on this point. So asking the WG again, I 
don't see how this would help.

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.

> While this seems like a delay, I will be speaking with the WG chairs on

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.

> interop efforts, and gain more experience.

There will be ISIS "homenet compliant" code by yokohama that has passed 
commercially available ISIS compliancy testing suites, and there will be 
two implementations written in two different programming languages both 
passing these tests.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 25 Jul 2015 12:20:43 +0200

> with dubious quality and working part of the time,

Mikael,

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

I'm not going to repeat my explanation here, I refer you to Section 7 of
draft-mrw-homenet-rtg-comparision-02.

> which a linkstate protcol such as ISIS can handle just fine.

Similar things have been done in link-state protocols.  I refer you to

 * Section 14 of RFC 3626;

 * http://www.olsr.org/docs/README-Link-Quality.html , which improves on
   the above;

 * http://pdos.csail.mit.edu/grid/mobicom03-mark-II.ppt , which describes
   the algorithm on which both the above and Appendix A.2.2 of RFC 6126
   are based;

 * draft-ietf-manet-olsrv2-dat-metric , a simplified version of ETT
   proposed by Henning.

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

> commercially available ISIS compliancy testing suites,

Excellent.  Now that we finally have a useful IS-IS spec (thanks, David),
we can communicate.

-- Juliusz

---

From: Gert Doering <[email-masked]>
Date: Sat, 25 Jul 2015 12:38:50 +0200

Hi,

> who see a more stable homenet which a linkstate protcol such as ISIS can 

Well, that argument seems just a little bit biased.

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.

[..]
> 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?

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

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Terry Manderson <[email-masked]>
Date: Sat, 25 Jul 2015 10:44:34 +0000

Hi Mark,

I'm not sure which hat you are wearing here - so I will presume none.

On 25/07/2015 5:40 am, "Mark Townsley" <[email-masked]> wrote:

>with closer participation from folks involved closely in Homenet since
>day one by including Ray. I'd suggest including a few open source
>implementors as well: David Lampeter, Stephen
> Barth, and Juliusz all come to mind if any would be so willing. To get
>additional operator viewpoint, perhaps Mikael Abrahamsson, John
>Brzozowski, and Barbara Stark. You might tap Hans Liu from D-Link as
>well. Perhaps even a call to the WG list for willing
> contributors.

I will not be adding further people (other than stated) to the design
team, should the design team need to reach out to the folks above for
clarifications - they are free to do so.

>
>I would like to echo here something I heard at the microphone on
>Wednesday: that the DT deliberations be more transparent, including at
>least read only access to the DT mailing list. The plan to produce an
>internet draft before Yokohama rather unveiling
> a powerpoint during the meeting itself is definitely a step in the right
>direction as well.

I will consider the request.

>ensure that we can continue to double down on moving forward our
>existing, non-routing-protocol, work. Terry,
> if you have any objection to that, please let us know now.

Yes, the WG should make efforts to move forward on in-charter,
non-routing-protocol work, and further ensure any decisions made are by
consensus.

Thanks
Terry

---

From: Sander Steffann <[email-masked]>
Date: Sat, 25 Jul 2015 13:46:11 +0200

Hi,

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

+1

> variant of homenet.  Why is the decision difficult?

I agree.
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 25 Jul 2015 15:21:18 +0200 (CEST)

On Sat, 25 Jul 2015, Gert Doering wrote:

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 25 Jul 2015 15:25:50 +0200 (CEST)

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.

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 25 Jul 2015 07:10:11 -0700

> 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

---

From: Gert Doering <[email-masked]>
Date: Sat, 25 Jul 2015 21:39:09 +0200

Hi,

> about interoperating ISIS implementations and its 20+ years of exposure to 

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

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 25 Jul 2015 22:24:15 +0200

> 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

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 25 Jul 2015 20:33:56 +0000

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

Regards,
Jeff

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 25 Jul 2015 20:50:06 +0000

-----Original Message-----
From: homenet [mailto:[email-masked]] 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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Jul 2015 20:33:14 -0400

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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Jul 2015 20:42:34 -0400

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 26 Jul 2015 00:56:01 +0000

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:[email-masked]]
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) <[email-masked]<mailto:[email-masked]>> 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.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Jul 2015 21:07:43 -0400

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

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.

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 26 Jul 2015 08:46:45 +0200

> 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

---

From: Sander Steffann <[email-masked]>
Date: Sun, 26 Jul 2015 14:07:25 +0200

Hi,

> Op 26 jul. 2015, om 03:07 heeft Ted Lemon <[email-masked]> het volgende geschreven:
> 

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

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Jul 2015 10:13:44 -0400

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

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 26 Jul 2015 16:36:41 +0200

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 <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Jul 2015 11:10:22 -0400

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 26 Jul 2015 19:18:14 +0000

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 <[email-masked]> a écrit :
>

---

From: Ray Bellis <[email-masked]>
Date: Sun, 26 Jul 2015 23:24:07 +0100

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

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

---

From: Gert Doering <[email-masked]>
Date: Mon, 27 Jul 2015 11:34:57 +0200

Hi,

[..]

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 27 Jul 2015 11:59:44 +0200

> 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

---

From: Henning Rogge <[email-masked]>
Date: Mon, 27 Jul 2015 12:17:00 +0200

> 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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 27 Jul 2015 12:04:28 +0000

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:[email-masked]] 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:

ROLL followed that path.

---

From: Margaret Cullen <[email-masked]>
Date: Mon, 27 Jul 2015 08:08:27 -0400

> 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

---

From: Gert Doering <[email-masked]>
Date: Mon, 27 Jul 2015 14:08:43 +0200

Hi,

> 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

---

From: "Jonathan Hansford" <[email-masked]>
Date: Mon, 27 Jul 2015 13:12:09 +0100

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

> From: homenet [mailto:[email-masked]] On Behalf Of Margaret
> Cullen
> Sent: 27 July 2015 13:08
> To: Hemant Singh (shemant) <[email-masked]>
> Cc: Pascal Thubert (pthubert) <[email-masked]>; Ted Lemon
> <[email-masked]>; Dino Farinacci <[email-masked]>; HOMENET
> <[email-masked]>; Mikael Abrahamsson <[email-masked]>; Gert
> Doering <[email-masked]>; Terry Manderson <[email-masked]>
> 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
> 
>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 27 Jul 2015 14:14:11 +0200

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 27 Jul 2015 14:15:38 +0200

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 27 Jul 2015 12:47:03 +0000

-----Original Message-----
From: Margaret Cullen [mailto:[email-masked]] 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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Jul 2015 09:14:12 -0400

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

---

From: Pierre Pfister <[email-masked]>
Date: Mon, 27 Jul 2015 20:33:37 +0200

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 27 Jul 2015 22:55:52 +0000

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:[email-masked]] 
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:

- Pierre

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 28 Jul 2015 01:45:15 +0200

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 27 Jul 2015 23:56:23 +0000

-----Original Message-----
From: Juliusz Chroboczek [mailto:[email-masked]] 
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

---

From: Gabriel Kerneis <[email-masked]>
Date: Tue, 28 Jul 2015 07:50:56 +0200

Hemant,

On Tue, Jul 28, 2015 at 1:56 AM, Hemant Singh (shemant) <[email-masked]>
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

---

From: Tore Anderson <[email-masked]>
Date: Tue, 28 Jul 2015 07:54:48 +0200

* "Hemant Singh (shemant)" <[email-masked]>

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

---

From: Dave Taht <[email-masked]>
Date: Tue, 28 Jul 2015 08:54:56 +0200

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Jul 2015 18:58:33 +1200

Hemant,

On 28/07/2015 10:55, Hemant Singh (shemant) wrote:
> Pierre,
> 
> Thanks.   Seeing other replies, I also hear a requirement (d) have plug-and-play routing, and (e) support MIF.  

By "MIF", do you mean multiple interfaces per host, or the MIF WG solution (MPVDs)?

The former is obvious but I'm not sure that any case has been made to require
MPVDs in the basic Homenet model. There are no references to the MIF WG or its
documents in the Homenet architecture RFC.

   Brian

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

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Jul 2015 10:38:38 +0200

Hi,

On Mon, Jul 27, 2015 at 10:55:52PM +0000, 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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 28 Jul 2015 11:08:07 +0200

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

---

From: Robert Cragie <[email-masked]>
Date: Tue, 28 Jul 2015 10:36:32 +0100

+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 <[email-masked]> 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?
>

---

From: Margaret Cullen <[email-masked]>
Date: Tue, 28 Jul 2015 08:41:52 -0400

> documents in the Homenet architecture RFC.

Since MPVDs are implemented on hosts, and informed by information distributed in RAs and/or via DHCP, Homenet should already support MPVDs to some extent.  There are some issues with how Homenet would distribute the MPVD DHCP options, most of which would apply to other container options, and we have a group of people looking into that now.  Assuming we can resolve those issues to everyone's satisfaction, Homenet will support MPVDs with no additional complexity in the Homenet protocols.

Margaret

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 28 Jul 2015 15:09:32 +0200

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> Tel: +49 (0)89/32356-444 <tel:%2B49%20%280%2989%2F32356-444>           USt-IdNr.: DE813185279
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/homenet <https://www.ietf.org/mailman/listinfo/homenet>
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2015 11:08:56 -0400

> 		time expanded on precisely not getting anywhere on this issue, arguing 

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.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 28 Jul 2015 17:12:26 +0200

> Since MPVDs are implemented on hosts, and informed by information distributed in RAs and/or via DHCP, Homenet should already support MPVDs to some extent.  There are some issues with how Homenet wo…

I think the reason why this "MIF support" thread started was that
different gateways might be good or bad (because of the topology/links
in between) for one router or the other one. The question is how to
push this local information to the attached Hosts.

Transporting DHCP options over HNCP has nothing to do with it, because
it will be a local decision anyways, not one decided by the gateway.

Henning Rogge

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 28 Jul 2015 17:19:04 +0200

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 <[email-masked]> wrote:
> 
> On Jul 28, 2015, at 9:09 AM, Thomas Clausen <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Sander Steffann <[email-masked]>
Date: Tue, 28 Jul 2015 17:57:29 +0200

Hi,

> 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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2015 11:58:48 -0400

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

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.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 28 Jul 2015 15:59:42 +0000

> 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

---

From: Paul Duffy <[email-masked]>
Date: Tue, 28 Jul 2015 12:10:35 -0400

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.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 28 Jul 2015 23:06:20 +0000

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:[email-masked]]
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) <[email-masked]<mailto:[email-masked]>> 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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 28 Jul 2015 23:25:04 +0000

-----Original Message-----
From: Juliusz Chroboczek [mailto:[email-masked]] 
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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 29 Jul 2015 09:59:29 +0200

> ISIS is many network topologies including mesh?

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

-- Juliusz

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 29 Jul 2015 10:48:07 +0000

-----Original Message-----
From: Juliusz Chroboczek [mailto:[email-masked]] 
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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 29 Jul 2015 12:07:39 +0000

> 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