Re: [homenet] Stub networks
On 9 Mar 2015, at 20:37, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks
On Mar 7, 2015, at 10:44 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Homenet --- A -- B || || C .. D (ZigBee) 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.) 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. -- Juliusz ___ 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
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.) 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks
On Mar 9, 2015, at 4:37 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: 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.) 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. 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. 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 ___ 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
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:homenet-boun...@ietf.org] On Behalf Of Juliusz Chroboczek Sent: Monday, March 09, 2015 1:38 PM To: Christian Hopps Cc: Ray Hunter; homenet@ietf.org; Ted Lemon Subject: Re: [homenet] Stub networks 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.) 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 ___ 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]
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
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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks
On 07 Mar 2015, at 16:54, Ted Lemon mel...@fugue.com wrote: On Mar 7, 2015, at 10:44 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: 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. 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. 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks
Homenet --- A -- B || || C .. D (ZigBee) 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks
On Mar 7, 2015, at 10:44 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: 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. 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks
On Mar 6, 2015, at 6:56 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Homenet --- A -- B || || C .. D (ZigBee) Why would you even autoconfigure a route at all between C and D? These are explicitly excluded in the homenet architecture. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks
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? 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 --- AB || || 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks
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 On 07/03/2015 12:56, Juliusz Chroboczek 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? 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 --- AB || || 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
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
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
