Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
Brian, Good points. See inline. Plus a new point below. In message 54f8ae20.5030...@gmail.com Brian E Carpenter writes: 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. 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. ... 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 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
Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
Juliusz Chroboczek wrote: 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 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
On 07/03/2015 01:02, Ray Hunter wrote: Juliusz Chroboczek wrote: 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 Good points. 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. 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
On Sat, 7 Mar 2015, Brian E Carpenter wrote: 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? 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 Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
On Mar 5, 2015, at 2:27 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: 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? 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 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] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
On 06/03/2015 09:19, Acee Lindem (acee) wrote: On 3/5/15, 2:46 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: 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. 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
On 06/03/2015 08:36, Christian Hopps wrote: On Mar 5, 2015, at 2:27 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: 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? 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? IMHO the second case applies - manual config may be possible, but the network must run correctly without it. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
