Subject: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Mar 2015 08:27:28 +1300

Hi,

> 8.  Support for Stub Networks and Stub Routers
...
>    IS-IS supports stub-networks as defined above
>    simply by advertising the prefix associated with a link, but not the
>    link itself.  This is sometimes referred to as a "passive link".
> 
>    Further an IS-IS router has the ability to set a bit (the overload
>    bit) to indicate that it should not be used for any transit traffic,
>    and that it will only be considered a destination for the prefixes it
>    has advertised, i.e., it is a stub router as defined above.
...
>    As all distance vector protocols, Babel supports fairly arbitrary
>    route filtering.  Designating a stub network is done with two
>    statements in the current implementation's filtering language.

In a homenet, there must be no manual config. In both cases, how does
this work automatically? How does IS-IS know not to advertise the link
and set the overload bit, and how does Babel know to include those
filtering rules? Or more generally, how does a stub router know that
it's a stub router, when there is no human to tell it so?

Regards
   Brian

---

From: Christian Hopps <[email-masked]>
Date: Thu, 5 Mar 2015 14:36:05 -0500

> On Mar 5, 2015, at 2:27 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

For IS-IS, the stub router would know so b/c it can’t be anything else. It is running the stub version of the software. The reason it would be doing this is b/c it’s a very small device not designed to do anything else.

BTW, is it true that there must be no manual config, or simply that one cannot rely on manual config?

Thanks,
Chris.

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 05 Mar 2015 20:46:31 +0100

> Or more generally, how does a stub router know that it's a stub router,
> when there is no human to tell it so?

Yeah, it's not very clear.  We were actually asked to describe the two
protocols' support for stub networks, and nobody never told us which of
the many definitions of stub network they meant, let alone describing the
use case precisely.  (The document uses the same definition as Cisco's
EIGRP documentation, in case you're interested.)

I'm imagining a dedicated device that has both a WiFi interface and
a low-power interface that acts as a gateway between the Homenet network
and the sensor network.  Such a device would come from the factory with
the low power interface configured as a stub.

-- Juliusz

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 5 Mar 2015 20:19:45 +0000

>the low power interface configured as a stub.

It is my understanding that this is the use case for auto-configured stub
routers as well. They are constrained devices that are only capable acting
as a stub router. 

Thanks,
Acee

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Mar 2015 11:17:18 +1300

> routers as well. They are constrained devices that are only capable acting

Yes, the idea that this an intrinsic property of certain devices
makes sense to me. If I buy a home climate control system that includes
a router to connect it to the rest of the homenet, it can "know" that
it's a stub router out of the box. What doesn't work for me is any
suggestion that somebody needs to configure this, because in 99% of
homes that isn't going to happen. The text in the draft could be a bit
clearer on this point.

Thanks
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Mar 2015 11:19:42 +1300

> BTW, is it true that there must be no manual config, or simply that one cannot rely on manual config?

IMHO the second case applies - manual config may be possible, but
the network must run correctly without it.

   Brian

---

From: Ray Hunter <[email-masked]>
Date: Fri, 06 Mar 2015 13:02:45 +0100

> the low power interface configured as a stub.

Good points.

My idea of a stub router is that the stub router itself knows it is a 
stub router.

Someone somewhere has said that this device will not forward packets on 
behalf of other devices.
Whether that's in the factory e.g. it runs a special version of the 
routing daemon, or because the device has been configured by the owner 
as a multi-homed host.

classic stub routers in EIGRP and IS IS are generally used to save 
bandwidth/ improve convergence times/ reduce memory utilisation/ improve 
route table stability on remote sites.

The main use case in Homenet that I have in mind is so that the "stub" 
device can advertise a stable loopback or other interface whilst 
changing it's attachment point to the rest of the homenet e.g. wifi 
roaming.

With those definitions in mind, I see little difference between a route 
filter configured on the full-blown homenet routers, and a route filter 
configured on the stub router device itself.

Given the stub router knows it's a stub router (by a mechanism outside 
of hnet or babel or IS IS), the obvious preference would be for any 
filters to be set up on the stub router itself.

e.g. use case of roaming node + stable addresses of other interfaces
outbound route advertisement filter =
permit directly connected interfaces
deny any

The list of directly connected interfaces can be easily automated 
without user intervention.

And if the use case is to preserve memory utilisation on small devices
inbound route advertisement filter on upstream interface to homenet =
permit default route
deny any

outbound route advertisement filter on upstream interface to homenet =
permit summary of all prefixes behind my downstream interface
deny any

the list of prefixes downstream is also known locally.

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Mar 2015 08:36:51 +1300

On 07/03/2015 01:02, Ray Hunter wrote:
> My idea of a stub router is that the stub router itself knows it is a stub router.

I thought for about 24 hours that this was indeed the answer to my question.
Well, it is, for routers that are designed, packaged, labelled and shipped
for a stubby purpose such as managing a bunch of thermostats or something.
What Ray says below applies to this case.

But now I don't see what's to stop a home user from buying a more
general-purpose router which happens to have a ZigBee port or something,
and plugging it in such a way that it *should* behave as a stub router.
How does it discover that and configure itself accordingly?

Saying that the user made a mistake or should have configured the
device is not an answer.

   Brian

> 
> Someone somewhere has said that this device will not forward packets on behalf of other devices.
> Whether that's in the factory e.g. it runs a special version of the routing daemon, or because the device has been configured by
> the owner as a multi-homed host.
> 
> classic stub routers in EIGRP and IS IS are generally used to save bandwidth/ improve convergence times/ reduce memory
> utilisation/ improve route table stability on remote sites.
> 
> The main use case in Homenet that I have in mind is so that the "stub" device can advertise a stable loopback or other interface
> whilst changing it's attachment point to the rest of the homenet e.g. wifi roaming.
> 
> With those definitions in mind, I see little difference between a route filter configured on the full-blown homenet routers, and
> a route filter configured on the stub router device itself.
> 
> Given the stub router knows it's a stub router (by a mechanism outside of hnet or babel or IS IS), the obvious preference would
> be for any filters to be set up on the stub router itself.
> 
> The list of directly connected interfaces can be easily automated without user intervention.
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 07 Mar 2015 00:56:55 +0100

> How does it discover that and configure itself accordingly?

Disclaimer: I know nothing about ZigBee.

My first reaction is that we'll cross that bridge when we come to it.

My second reaction is that in a properly functioning network, the ordinary
mechanisms of the routing protocol will effectively treat the link as
a stub.  If the topology is just

   Homenet --- A ........
                 (ZigBee)

then obviously the ZigBee link will not be used for transit.  If the
topology is redundant:

   Homenet --- A ------ B
               |        |
               |        |
               C ...... D
                (ZigBee)

then the routing protocol should assign a sufficiently high metric to the
ZigBee link, so that in effect it will be treated as a stub link.
(Disclaimer: the current implementation of Babel doesn't do that yet, it
currently only has a taxonomy of wired/wireless/bridged/BATMAN, I'm quite
willing to implement it if somebody has a suitable device to test on.)

Where you run into trouble is when the Homenet topology is not redundant
enough, and there is a fault on the Homenet side:

   Homenet --- A        B
               |        |
               |        |
               C ...... D
                (ZigBee)

Here, no matter how high the metric of the ZigBee link, Homenet traffic
from A to B will want to go through it.  If A is your NAS and B is your
TV, then an attempt to start a streaming session may bring the ZigBee link
to its knees.

My third reaction is that this should be avoided by proper AQM on the
ZigBee link, but I don't know anything about AQM for ZigBee, so I'll shut
up.

So in summary, the stub functionality is only necessary when (1) the
topology is redundant, (2) the ZigBee link doesn't have adequate AQM, and
(3) the ZigBee link needs to remain functional even when the Homenet gets
otherwise partitioned.  While I agree that there are useful use cases for
that (you certainly want your thermostat to keep functioning even when
somebody unplugged the Ethernet from your television), frankly, I'm not
going to loose too much sleep over that.

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Mar 2015 13:56:15 +1300

Juliusz,

I like your analysis, and I think it needs to be included in a
homenet document. It doesn't really belong in the routing
protocol comparison, although it may call for some requirements
for router implementations. Maybe there is a homenet "router
requirements" draft in our future.

Regards
   Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Mar 2015 20:04:21 -0500

>                (ZigBee)

Why would you even autoconfigure a route at all between C and D?   These are explicitly excluded in the homenet architecture.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 7 Mar 2015 05:49:57 +0100 (CET)

> How does it discover that and configure itself accordingly?

It's my understanding that the stubbyness is a property of the hardware 
capability, not topology or interfaces. There is nothing that stops a 
capable router to have a Zigbee port and announce that port to the 
homenet.

The reason for "stub router" is that it's more lightweight than a full 
router, it's not that a Zigbee router must be a stub router.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 07 Mar 2015 16:44:22 +0100

> Why would you even autoconfigure a route at all between C and D?

I think that you and Mikael expect that the ZigBee link will be designated
as stub, while Brian, ever the pessimist, expects things to go wrong
whenever they can.  I happen to agree with Brian.

(Which, by the way, is the reason why I think that the way networks
containing both IS-IS and Homenet IS-IS will silently break is a major
f*ck up.  Section 6.3.  Yeah, I was too tired to argue that point.)

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Mar 2015 10:54:28 -0500

> whenever they can.  I happen to agree with Brian.

We can't prevent people from doing stupid things, but we can at least give good advice.   I think the advice we would want to give is that a router that has a zigbee interface SHOULD NOT advertise routes that transit that link, although they SHOULD advertise routes _to_ that link.   I will admit that I am not exactly an expert on the topic, but this doesn't seem like rocket science.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 07 Mar 2015 16:59:41 +0100

> We can't prevent people from doing stupid things, but we can at least
> give good advice.

I think that we're in violent agreement.

-- Juliusz

---

From: V6ops <[email-masked]>
Date: Sat, 7 Mar 2015 18:51:57 +0100

> On 07 Mar 2015, at 16:54, Ted Lemon <[email-masked]> wrote:
> 

My reasoning for asking for stub router support has more to do with the capability of devices e.g. How many lines of code the device needs to support, how difficult is zeroconf, how much memory the device needs, whether it needs to wake up from sleep on a topology change and thus drain the battery; rather than any requirements on best path selection.

IMHO Routing protocols will do a fine job of picking the correct path, provided we specify the correct default metrics somewhere. If the last resort path is over mesh wifi, so be it.

I see no reason to limit this via an arbitrary technology decision in the architecture. One of my friends ISP links runs over long range wifi in a rural area and it works fine. Radio between buildings over a public highway would be another use case.

The zigbee example to me has more to do with the link technology being unsuitable because of its low power requirements and support for applications requiring long battery life, rather than anything else. Having all of these devices wake up whenever a mobile phone tethers to somewhere else in the Homenet would be daft. By using a stub router, anything behind the stub router can remain asleep during this topology change.  The stub router itself could be mains powered and route to (yet to be developed) multi hop routed networks.

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 08 Mar 2015 22:41:37 -0400

Brian,

Good points.  See inline.  Plus a new point below.

In message <[email-masked]>
> >    has advertised, i.e., it is a stub router as defined above.

In both ISIS and OSPF is an neighbor adjacency is formed with another
router, the adjacency to a network pseudonode is advertised.  If no
other router is found, then no pseudonode is formed and just the
prefix is announced as a stub.

> it's a stub router, when there is no human to tell it so?

Another topic comes to mind.  The topic is the partitioned bridged
network.  It looks like this.

  +-------+                                  +-------+
  | Rtr#1 |------------- Link#1 -------------| Rtr#2 |
  +-------+                                  +-------+
      |                                          |
    ... other links                            ... other links
      |                                          |
  +-------+                                  +-------+
  | Rtr#3 |------------- Link#2 -------------| Rtr#4 |
  +-------+                                  +-------+
      | I#3                                      | I#4
      |                                          |
  +-------+                                  +-------+
  |  Sw#1 |-----------/  broken  /-----------|  Sw#2 |
  +-------+       same subnet numbering      +-------+
      |                                          |
      |                                          |
   +--/--- ... ---/--+            +--/--- ... ---/--+
      |           |                  |           |
      |           |                  |           |
  +-------+     more               more      +-------+
  | host1 |     subnet             subnet    | host2 |
  +-------+     drops              drops     +-------+

    legend:  Rtr# = a router; I# = an interface

    example:  I#3= 192.0.2.1; I#4= 192.0.2.2; subnet= 192.0.2/24
              In IPv6, make that 2001:db8:fff0::/64

In this example all of the host and router interfaces are up.  This is
not a misconfiguration.  Some bridging was used and a link between
bridges is down.

In ISIS and OSPF both the interface on the router and the prefix is
advertised.  In ISIS and OSPF sometimes just the prefix is advertised
to save on /32 (/128) prefixes floating about, but that affects some
reachability to router interface addresses (but never to the loopback
if numbered, which is why they are always numbered in ISP networks).
That makes two ways to reach the subnet, and therefore to reach host1
and host2 when bridging is working.

In ISIS and OSPF when this link between bridges goes down, the routers
are always reachable through their loopback addresses.  If pinging the
interface is desireable, mostly just so as not to confuse operators
doing manual ping, the router interfaces can be advertised and they
are always reachable.  The hosts, in this example, host1 and host2,
but potentially quite a few more, are only reachable from parts of the
network.  Any router closer in the topology to Rtr#3 including Rtr#3
can't reach host2.  Any router closer in the topology to Rtr#4
including Rtr#4 can't reach host1.

One solution for an ISP where host1 and host2 are important (for
example NMS data collection nodes), is to run ISIS or OSPF on the host
and make them stub routers if they are multihomed (the old way before
stub router support was set cost to a very high number).  This was
done in the gated days (gated is an older routing daemon) but is
doable with Bird or Quagga.  This yielded a slow switchover, but a
reliable one.

Mostly reliable.  Some routers didn't install the interface addresses
in the FIB (falsely assuming that the subnet address was plenty) but
they were beat up about it, so maybe that problem is gone.

BTW- If there were other routers still connected to Rtr#3 or Rtr#4,
then a DR and BDR was elected and the network pseudonode with save
prefix was advertised from more than one router.

This is why ISPs don't particularly care for switched networks.

Even if an address is configured on the host loopback and advertise it
as a /32 or /128 stub from the routers on that subnet, it doesn't
help.  Reachability to the host has to be determined somehow.

I don't see how this can be fixed without some change to the host to
establish liveness wrt the indiviual routers on the subnet.

Given a means to determine liveness to hosts, the hosts can be
advetised as stubs with zero configuration.  Otherwise just the subnet
is advertised from two places and this situation isn't fixable.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Mar 2015 01:33:45 -0400

In message <[email-masked]>
Ted Lemon writes:
 
> give good advice.  I think the advice we would want to give is that a
> router that has a zigbee interface SHOULD NOT advertise routes that
> transit that link, although they SHOULD advertise routes _to_ that
> link.  I will admit that I am not exactly an expert on the topic, but
> this doesn't seem like rocket science.

I agree.  But ZigBee is not a link it is a low power bridged network,
or at least it started out bridged.

A ZigBee gateway is an application gateway running an RPC protocol
based on SOAP.

ZigBee IP seesm to be something new which embraces 6LoPAN and the ROLL
WG's RPL and adds a ZigBee trademark to it.
http://www.embedded.com/design/connectivity/4419558/Zigbee-s-new-IP-specification-for-IPv6-6LoPAN-wireless-network-designs
http://www.embedded.com/electronics-news/4411167/Zigbee-releases-spec-for-IPv6-based-wireless-mesh-networks
http://www.zigbee.org/zigbee-for-developers/network-specifications/zigbeeip/

Curtis

---

From: Christian Hopps <[email-masked]>
Date: Mon, 9 Mar 2015 07:56:00 -0400

> f*ck up.  Section 6.3.  Yeah, I was too tired to argue that point.)

The user would have to go out of their way to configure their non-homenet IS-IS router specifically to interoperate with the homenet IS-IS. How would they know how to do this other than to be familiar with the other requirements? It’s not like they would be able to accidentally drop a non-homenet IS-IS router into their network and have it start silently failing.

Thanks,
Chris.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 09 Mar 2015 21:37:32 +0100

>> Brian, ever the pessimist, expects things to go wrong whenever they
>> can.  I happen to agree with Brian.
>>

> The user would have to go out of their way to configure their
> non-homenet IS-IS router specifically to interoperate with the homenet
> IS-IS. How would they know how to do this other than to be familiar with
> the other requirements? It’s not like they would be able to accidentally
> drop a non-homenet IS-IS router into their network and have it start
> silently failing.

It's 2017.  There's an animated discussion on Stackoverflow about how to
install IS-IS on an ordinary PC in order to get it to interoperate with
Homenet.  There are some people who point out that the Homenet variant of
IS-IS is not interoperable with stock IS-IS, but they get voted down.
``Haters will hate, but I've been running it that way for three days and
it works just fine''.

I'm not asking for full interoperability, I just wish source-specific
IS-IS would refuse to establish neighbour relationships with non-specific
IS-IS.  We'll pay for that mistake at some point.

Ted once wrote that we cannot prevent people from being stupid.  Ted is of
course right, but I still think that we should strive to minimise the
consequences of human stupidity.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 09 Mar 2015 21:57:18 +0100

> network.

    The first situation was informally described by R. Tomlinson as
    a "network partitioning" problem in which a particular host, H in
    network N, is reachable from one gateway attached to network N but not
    another, because network N has become partitioned into two or more
    pieces.

    [...]

    The third situation arises in connection with an advanced airborne
    packet radio application.  It first emerged in conversations with
    Major L. Druffel of the DARPA/IPT office.  In this case, long-range
    packet radios (200-300 miles) are installed in aircraft and on the
    ground at selected sites.  The ground sites may or may not have
    connectivity with each other (e.g., through a wire network and
    gateways).  While aircraft are aloft, they communicate with each other
    and the ground via packet radios.  If we treat the ground packet radio
    networks as a single net (for internet addressing purposes) and
    include the airborne packet radios as a part of that net, then this
    creates the partitioned network problem which was raised by
    R. Tomlinson.

    -- Vint Cerf, IEN 110, 1979

While I happen to be an advocate of advertising a /128 on the host, as you
suggest, I'd like to point out that HNCP might finally solve this 40
year-old issue.  Draft-ietf-homenet-prefix-assignment is not very clear on
this issue, but I think that it implies that the algorithm is re-run when
a link is partitioned -- which causes renumbering and causes two prefixes
to be assigned to the now partitioned link.

Pierre, is that correct?  Does it need clarifying in your draft?

Interestingly enough, the memo cited above describes the issue of
multihomed hosts losing TCP connections when one of the networks goes
down -- an issue that MP-TCP is finally solving 40 years later.

-- Juliusz

---

From: Christian Hopps <[email-masked]>
Date: Mon, 9 Mar 2015 19:03:32 -0400

> On Mar 9, 2015, at 4:37 PM, Juliusz Chroboczek <[email-masked]> wrote:
> 

But I say we are doing that by using a homenet specific authentication password, a non-homenet router will not form adjacencies with a homenet router. Yes the user can bypass this forcefully, but that doesn’t mean we haven’t addressed the issue. Anyway I guess we disagree.

Thanks,
Chris.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 10 Mar 2015 04:11:09 +0000

Juliusz -

If you were present at the IS-IS-WG meeting  in Honolulu (if not consult the minutes and/or read the list archives) you may remember that there was a good deal of discussion about this problem in the context of http://www.ietf.org/id/draft-lamparter-isis-reachability-critical-subtlvs-00.txt.

The strong recommendation of myself and others was to use a reserved MTID for Homenet networks. In such a case even if a non-Homenet IS-IS router formed an adjacency with a Homenet IS-IS router they would never see each other in the same topology so neither would be part of the topology specific SPT and neither would try to forward anything via the other. 

So this problem is easily addressed...

   Les

> -----Original Message-----
> From: homenet [mailto:[email-masked]] On Behalf Of Juliusz
> Chroboczek
> Sent: Monday, March 09, 2015 1:38 PM
> To: Christian Hopps
> Cc: Ray Hunter; [email-masked]; Ted Lemon
> Subject: Re: [homenet] Stub networks
> 
> >> containing both IS-IS and Homenet IS-IS will silently break is a
> >> major f*ck up.  Section 6.3.  Yeah, I was too tired to argue that
> >> point.)
> 
> > IS-IS. How would they know how to do this other than to be familiar
> > with the other requirements? It’s not like they would be able to
> > accidentally drop a non-homenet IS-IS router into their network and
> > have it start silently failing.
> 
> install IS-IS on an ordinary PC in order to get it to interoperate with Homenet.
> There are some people who point out that the Homenet variant of IS-IS is
> not interoperable with stock IS-IS, but they get voted down.
> ``Haters will hate, but I've been running it that way for three days and it
> works just fine''.
> 
> I'm not asking for full interoperability, I just wish source-specific IS-IS would
> refuse to establish neighbour relationships with non-specific IS-IS.  We'll pay
> for that mistake at some point.
>

---

From: Ray Bellis <[email-masked]>
Date: Tue, 10 Mar 2015 09:11:42 +0000

> On 9 Mar 2015, at 20:37, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Homenet.

The question will get closed because it's off topic.

If we've done our job properly, Homenet questions will be on topic for superuser.com, because serverfault.com is reserved for "professional server and network management related questions".

;-)

Ray

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 16 Mar 2015 21:07:43 -0400

In message <[email-masked]>

Juliusz,

If HNCP renumbers on a partition, then existing TCP connections would
drop.

Numbering the loopback avoids this.  Also there is the solution used
in the 1990s by ISPs which you trimmed from my email, but requires
installing host routes.

Also consider what might happen with an intermittent link between
switches if the solution is to renumber on a subnet partition (which
should occur, but for the interface addresses only, if not using link
local).

My preferred solution is:

  1) always number the loopback except for legacy hosts,

  2) use link local interface addresses on a point to point interface
     including Ethernet with two hosts except for legacy hosts,

  3) number any broadcast interface using HNCP (or since this is my
     preference, extend OSPF - no flames please).

Thanks for the historic reference.

Curtis

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 17 Mar 2015 10:43:17 +0100

I've trimmed it because I fully agree with it:

>> While I happen to be an advocate of advertising a /128 on the host, as
>> you suggest,

Host routes within the homenet are a goodness.

-- Juliusz

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Mar 2015 22:10:10 +0900

> Host routes within the homenet are a goodness.

You need to renumber anyway when an external link goes down. What do you
gain by not renumbering in a subset of cases?