[homenet] MIF support [was Moving forward.]
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. > > Thanks, > > Hemant > > -Original Message- > From: Pierre Pfister [mailto:pie...@darou.fr] > Sent: Monday, July 27, 2015 2:34 PM > To: Hemant Singh (shemant) > Cc: Pascal Thubert (pthubert); Ted Lemon; HOMENET; Terry Manderson; Gert > Doering; Dino Farinacci; Mikael Abrahamsson > Subject: Re: [homenet] Moving forward. > > > I just spent one hour at my sister’s home trying to optimize the positioning > of a WiFi repeater. > Her home is definitely an average-sized one, with average people living in it > that do not know anything about IP networking. > But they have an ethernet link, a PLC link because the ISP told them to use > it, and a dummy wifi repeater which does some black magic to extend the wifi > network without requiring more configuration. > > So I’d say: > (c) A home network may have multiple wifi links. Some of which may be used > for transit. > > - Pierre > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
I would like to *require* of the "design team" that they actually install the available software on at least three routers and try it. I would certainly like to require of the working group the same, but despite 2 years of trying, have lost hope. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
* "Hemant Singh (shemant)" > (c) An average home has one wifi link. I think you'll find that an "average" home has more than 1 wifi link. Maybe somewhere between 1 and 2 is the correct number. For example: The concrete between the two floors in my apartment makes an AP located upstairs practically unusable from downstairs and vice versa. So I have two bridging APs that share the same ESSID and are connected to the same wired layer-2 segment. That works well enough. Tore ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
-Original Message- From: Juliusz Chroboczek [mailto:j...@pps.univ-paris-diderot.fr] Sent: Monday, July 27, 2015 7:45 PM To: Hemant Singh (shemant) Cc: HOMENET Subject: Re: [homenet] Moving forward. >I may have misunderstood -- but are you saying that you have the technology to >perform bidirectional redistribution between two very different routing >protocols in an unadministered network, and >guarantee the absence of >persistent routing loops without making any assumptions about the topology? >If so, I would humbly request a pointer to this extremely cool technology. Have you run, say, RIPng, on one network interface facing the interior of a network while running IS-IS on another interface on the same router? Once each routing is configured and redistributing routes between, what is the issue? The prefixes between each routing are disjoint. Hemant ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
> I would break down the problem by using Babel on the wifi links and > IS-IS on the wired link - what do folks think? If each of Babel and > IS-IS are auto-configurable or close to it, the two combined can be > auto-configurable as well. They each have to distribute their > static and connected routes to each other and such a distribution > can totally be automated. I may have misunderstood -- but are you saying that you have the technology to perform bidirectional redistribution between two very different routing protocols in an unadministered network, and guarantee the absence of persistent routing loops without making any assumptions about the topology? If so, I would humbly request a pointer to this extremely cool technology. -- Juliusz (humbled) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
Pierre, Thanks. Seeing other replies, I also hear a requirement (d) have plug-and-play routing, and (e) support MIF. I think plug-and-play is a work in progress until routing is decided. I would break down the problem by using Babel on the wifi links and IS-IS on the wired link - what do folks think? If each of Babel and IS-IS are auto-configurable or close to it, the two combined can be auto-configurable as well. They each have to distribute their static and connected routes to each other and such a distribution can totally be automated. Thanks, Hemant -Original Message- From: Pierre Pfister [mailto:pie...@darou.fr] Sent: Monday, July 27, 2015 2:34 PM To: Hemant Singh (shemant) Cc: Pascal Thubert (pthubert); Ted Lemon; HOMENET; Terry Manderson; Gert Doering; Dino Farinacci; Mikael Abrahamsson Subject: Re: [homenet] Moving forward. I just spent one hour at my sister’s home trying to optimize the positioning of a WiFi repeater. Her home is definitely an average-sized one, with average people living in it that do not know anything about IP networking. But they have an ethernet link, a PLC link because the ISP told them to use it, and a dummy wifi repeater which does some black magic to extend the wifi network without requiring more configuration. So I’d say: (c) A home network may have multiple wifi links. Some of which may be used for transit. - Pierre ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] some IS-IS questions
-Original Message- From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of STARK, BARBARA H Sent: Monday, July 27, 2015 4:50 PM To: homenet@ietf.org Subject: [homenet] some IS-IS questions >Given some of the discussion last week, I found that I had some questions >about what is or isn't already defined somewhere within the set of IS-IS specs >*and* is already implemented in a load suitable >for a homenet router. I've >read the Babel specs, so I have a good idea of what's in Babel. Plus there was >that really good Babel presentation Thursday night. But I'm having real >trouble finding the right IS->IS specs to answer my questions. >There was a claim that IS-IS provides "diagnostics". >What sort of diagnostics? http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r43/routing/configuration/guide/b_routing_cg43xasr9k/b_routing_cg43xasr9k_chapter_01011.html#concept_B475330101904631B14C625066A033C3 Search at the above URL for " Route Convergence Monitoring and Diagnostics". >Is this a reference to topology discovery? Does topology discovery rely on >device participation in IS-IS, or can devices that do not participate in IS-IS >be discovered? All devices in the IS-IS domain need to be routers. Neighboring routers find each other by exchanging Hellos using multicast. Loosely speaking, an IS-IS router uses link-state packet (LSP) to flood learnt prefixes and topology to neighbors. IS-IS supports both IPv4 and IPv6 easily. >Can bridged devices be discovered? Yes/No. The bridge would need to be a RBridge such as in TRILL and then the bridge can be discovered. Or if the bridge is connected to an IS-IS router or a switch connected to the IS-IS router, the router/switch can learn the end bridged device mac-address. The learnt mac-address can be propagated to IS-IS using a sub TLV in IS-IS. > If yes, can they be discovered even if they don't do IS-IS? If yes, how does > that work? See above. >Can physical layer topology be discovered? IS-IS knows who its neighbors are and also knows the path to any other neighbor. Wouldn't this suffice? Or please give an example of a physical layer topology that the network layer is not able to provide. >What additional diagnostics outside of topology discovery does IS-IS support? See the URL I mentioned above. >I was told that IS-IS can help avoid loops caused by bridged interfaces as >well as routed interfaces? Is this correct? Not quite. When IS-IS was added to RBridges by TRILL, it is the TRILL header that includes a Hop count that helps avoid routing loops, not IS-IS. IS-IS is a connection-less protocols and thus a TTL (or hop count) in the IPv4 header cannot be leveraged to avoid loops. IS-IS avoid loops as soon as the new network topology is flooded to all the routers within the routing area. >If yes, does it rely on participation of bridges in IS-IS, or can it be done >with only participation by routers? See above. >I was told that with IS-IS a "service provider" router could somehow >automatically take control of QoS and routing policy in the network, and >dictate policy to other routers (assuming the other routers >even have a QoS >policy). Is this true? How does this work, especially if there are multiple >"service provider" routers? Would this be in the IS-IS version suitable for >homenet? The home router does not include the WAN interface in LAN routing whether the routing is IS-IS or another routing protocol. Then IS-IS only operates in the home LAN. I defer to others to signaling QoS with IS-IS or taking over routing policy. IS-IS is flexible and adds new functionality in a jiffy using TLV option and sub-TLV options. >I was told that if IS-IS is selected, hosts will be able to do resource >reservation across the homenet. Resource reservation has yet to be implemented >in unmanaged home network devices, though many >standards have been written. >In general, the complexity of supporting resource reservation schemes has >never been worth the cost. Is this something that will suddenly work as a >result of IS-IS >implementation in routers? Is it in the IS-IS subset proposed >for homenet? What does it require in the hosts? IS-IS has no implication on hosts. Resource reservation using RSVP is performed for QoS in the Internet. IS-IS runs in the LAN. Hemant ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] some IS-IS questions
Given some of the discussion last week, I found that I had some questions about what is or isn't already defined somewhere within the set of IS-IS specs *and* is already implemented in a load suitable for a homenet router. I've read the Babel specs, so I have a good idea of what's in Babel. Plus there was that really good Babel presentation Thursday night. But I'm having real trouble finding the right IS-IS specs to answer my questions. There was a claim that IS-IS provides "diagnostics". What sort of diagnostics? Is this a reference to topology discovery? Does topology discovery rely on device participation in IS-IS, or can devices that do not participate in IS-IS be discovered? Can bridged devices be discovered? If yes, can they be discovered even if they don't do IS-IS? If yes, how does that work? Can physical layer topology be discovered? What additional diagnostics outside of topology discovery does IS-IS support? I was told that IS-IS can help avoid loops caused by bridged interfaces as well as routed interfaces? Is this correct? If yes, does it rely on participation of bridges in IS-IS, or can it be done with only participation by routers? I was told that with IS-IS a "service provider" router could somehow automatically take control of QoS and routing policy in the network, and dictate policy to other routers (assuming the other routers even have a QoS policy). Is this true? How does this work, especially if there are multiple "service provider" routers? Would this be in the IS-IS version suitable for homenet? I was told that if IS-IS is selected, hosts will be able to do resource reservation across the homenet. Resource reservation has yet to be implemented in unmanaged home network devices, though many standards have been written. In general, the complexity of supporting resource reservation schemes has never been worth the cost. Is this something that will suddenly work as a result of IS-IS implementation in routers? Is it in the IS-IS subset proposed for homenet? What does it require in the hosts? Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Most simple example "lossy routing" setup / value prop ?
> If you have code that detects a PoE adapter and that comes with a license > that I can use, I'm interested. (Barbara mentioned an IEEE standard that aims > at doing that, but I don't think it's being deployed yet.) Yes, I'd mentioned IEEE 1905.1a. IEEE 1905 (which includes support for HomePlug AV, but not G.hn) is being deployed some, but I don't know how widely. I'd suggested IETF request a copy via liaison, but no liaison was ever sent. BTW, if such a liaison were to be sent to IEEE 1905 working group before 11 August, I have reason to believe the group would be happy to try to get a copy to IETF. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Most simple example "lossy routing" setup / value prop ?
> There is no deployment chicken & egg problem, right ? Consumers do > deploy powerline, APs on powerline are becoming more popular, so another > SSID between the APs as another path seems to be easily in the grasp of > the device vendor, and should help to much better upsell the product... Good point. Unfortunately, babeld (the implementation) does not currently have any support for detecting PoE -- and since PoE adapters appear to the router as ordinary Ethernet switches, I'm not sure what can be done about it. If you have code that detects a PoE adapter and that comes with a license that I can use, I'm interested. (Barbara mentioned an IEEE standard that aims at doing that, but I don't think it's being deployed yet.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Most simple example "lossy routing" setup / value prop ?
On Mon, Jul 27, 2015 at 09:18:25PM +0200, Juliusz Chroboczek wrote: > In-charter example: Section 7 of draft-mrw-homenet-rtg-comparison-02: > > https://tools.ietf.org/html/draft-mrw-homenet-rtg-comparison-02#section-7 > > Out-of-charter example with formal evaluation: > > http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1747&context=infopapers Thanks for the pointers! > Home networks currently have a degenerate tree topology (a single NAT box > with two to five connected links), with no path diversity whatsoever, and > hence no optimisation opportunities. Smart routing protocols will only > become an issue once we have more exciting topologies in home networks. > > Yes, I know, chicken and egg. Well, how about my example ? There is no deployment chicken & egg problem, right ? Consumers do deploy powerline, APs on powerline are becoming more popular, so another SSID between the APs as another path seems to be easily in the grasp of the device vendor, and should help to much better upsell the product... And given how i can not buy this, something is missing here, and i wonder what it is ;-)) Cheers Toerless > -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Most simple example "lossy routing" setup / value prop ?
> Where would i find a simple 2 page user-facing whitepaper explaining > what the minimum topology at home is where babel provides better > user experience over the alternatives, and how exactly the user benefits. In-charter example: Section 7 of draft-mrw-homenet-rtg-comparison-02: https://tools.ietf.org/html/draft-mrw-homenet-rtg-comparison-02#section-7 Out-of-charter example with formal evaluation: http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1747&context=infopapers (Note that this paper compares Babel, which aims at being a generalist routing protocol, with dedicated mesh protocols that are presumably fine-tuned for this kind of topology.) > why are home router vendors not all over it ? Home networks currently have a degenerate tree topology (a single NAT box with two to five connected links), with no path diversity whatsoever, and hence no optimisation opportunities. Smart routing protocols will only become an issue once we have more exciting topologies in home networks. Yes, I know, chicken and egg. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Most simple example "lossy routing" setup / value prop ?
On Jul 27, 2015, at 2:53 PM, Toerless Eckert wrote: > How about comparing to what happens outside the home: Provider are > now offering hybrid DSL+LTE. Is that using any dynamic load distribution > to cope with the variability of LTE ? If this is a case where dynamic > traffic distribution makes sense, how would Babel fare in that setup > compared to what is being done in those DSL+LTE networks today ? Generally speaking I’m pretty skeptical of these solutions. We’ve heard about them in homenet and mif. They try to solve the multihoming problem transparently, with a single prefix, and that makes sense if you don’t have a better option, but it would be nice to solve the problem at the IP layer in a way that doesn’t hide the actual topology of the network. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Most simple example "lossy routing" setup / value prop ?
Just following the Babel vs. IS-IS discussion on the side line and have no opinion one way or the other, so i hope it's not to inciting to ask candidate consumer question: Where would i find a simple 2 page user-facing whitepaper explaining what the minimum topology at home is where babel provides better user experience over the alternatives, and how exactly the user benefits. And if this is obvious... why are home router vendors not all over it ? So far i could only figure that i need alternative paths, if one alternative path is great working wired, its unlikely to be interesting to have dynamic alternatives. So maybe i need a bunch of homenet powerline APs that can talk with each other also via WiFi so i have two potentially fast but more likely varyingly crappy paths (powerline/wifi). I can see how dynamic traffic balancing wifi/powrline and multi-hop wifi AP to AP wifi path selection could be a killer feature killer here, but i have seen no data, and it's definitely quite advanced. And i am only guessing. Maybe there is some more obvious topology i am forgetting. If not for home, How much is babel used in the military, oops: "MANET" enviroments ? Maybe thats where i could find deployment benefit examples ? How about comparing to what happens outside the home: Provider are now offering hybrid DSL+LTE. Is that using any dynamic load distribution to cope with the variability of LTE ? If this is a case where dynamic traffic distribution makes sense, how would Babel fare in that setup compared to what is being done in those DSL+LTE networks today ? Cheers Toerless ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
> > (c) An average home has one wifi link. > I just spent one hour at my sister’s home trying to optimize the positioning of a WiFi repeater. Her home is definitely an average-sized one, with average people living in it that do not know anything about IP networking. But they have an ethernet link, a PLC link because the ISP told them to use it, and a dummy wifi repeater which does some black magic to extend the wifi network without requiring more configuration. So I’d say: (c) A home network may have multiple wifi links. Some of which may be used for transit. - Pierre ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] apologies
First, I would like to apologize for shouting during the meeting. As many of you may feel, I was caught up in my concerns that we find a way through the consensus process to pick a mandatory-to-implement routing protocol so that homenet - and the many many many people and businesses that will depend on it - can succeed. Although only recently paying attention to homenet, I have heard how many of you are frustrated by the long time trying to get to consensus had taken. I deeply share this frustration. The passion and energy in that room tells me how deeply you all care about finding a technical solution that will succeed. I hope that we can do that together. Regards, Alia ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
> not all clients support getting RDNSS and search-domains from RAs > (e.g. Windows-based). I can give you a Linux CD ;-) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
> There's no "attached host control" part in HNCP -- there's just RA and > DHCPv4 (DHCPv6 optional). HNCP is purely a router-router protocol. (stateless) DHCPv6 is mandatory as per RFC 7084, since not all clients support getting RDNSS and search-domains from RAs (e.g. Windows-based). In general, while having something minimal in there is nice, I think making it optional or at least separating it so it can be easily removed is a good idea as well. For some stuff you might not want to have DHCPv4 / IPv4, or you want to have a better-featured RA-server that actually reacts to default route changes, or sends out link MTU & HW-address or can unicast replies etc. All in all, that's some modularity even hnetd has :P Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
On Mon, Jul 27, 2015 at 5:42 PM, Juliusz Chroboczek wrote: >> I wonder if the "data-propagation/router control" part of HNCP and the >> "attached host control" part of HNCP should be split into two >> entities... this would allow the second one to get hints from the >> routing protocol about the metric without generating a dependency >> cycle. > > There's no "attached host control" part in HNCP -- there's just RA and > DHCPv4 (DHCPv6 optional). HNCP is purely a router-router protocol. you could say that setting your local prefix on the interface is "control the local node" and setting up RA/DHCPv4 is "control the address of the host". still, at the moment I just see a problem and have no good solution, just a few guesses. > It's a pretty clean design. > > In principle, it might be possible to use routing protocol metrics to > influence RFC 4191 preferences, but I'm not sure how that would work. > If you know (and have implementation experience), I'm interested. I just got my olsrv2 implementation source-specific routing capable... I plan to look at your "simple" HNCP implementation to see how routing metrics could help. But this is still a "todo" for me. Henning ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
> I wonder if the "data-propagation/router control" part of HNCP and the > "attached host control" part of HNCP should be split into two > entities... this would allow the second one to get hints from the > routing protocol about the metric without generating a dependency > cycle. There's no "attached host control" part in HNCP -- there's just RA and DHCPv4 (DHCPv6 optional). HNCP is purely a router-router protocol. It's a pretty clean design. In principle, it might be possible to use routing protocol metrics to influence RFC 4191 preferences, but I'm not sure how that would work. If you know (and have implementation experience), I'm interested. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
On Mon, Jul 27, 2015 at 4:15 PM, Juliusz Chroboczek wrote: >> if HNCP redistributes assigned prefixes into the RA/DHCPv4 servers, >> who makes sure that these are prefixes that are "reasonable good" >> measured by the metric of the routing protocol? > > Nobody. From the point of view of the host, all connected routers are > equivalent. > > If the host is single-homed, any suboptimal routing will be resolved by > the redirect mechanism. If the host is multi-homed, there's a realistic > risk of suboptimal routing -- I don't know any good solution to that (but > I haven't looked carefully at the MIF work). I wonder if the "data-propagation/router control" part of HNCP and the "attached host control" part of HNCP should be split into two entities... this would allow the second one to get hints from the routing protocol about the metric without generating a dependency cycle. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
> The situation with DHCPv4 is not as satisfactory [...] > (FORCERENEW is not useful). Roy Marples, the author of dhcpcd, is telling me to look at RFC 6704. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
> if HNCP redistributes assigned prefixes into the RA/DHCPv4 servers, > who makes sure that these are prefixes that are "reasonable good" > measured by the metric of the routing protocol? Nobody. From the point of view of the host, all connected routers are equivalent. If the host is single-homed, any suboptimal routing will be resolved by the redirect mechanism. If the host is multi-homed, there's a realistic risk of suboptimal routing -- I don't know any good solution to that (but I haven't looked carefully at the MIF work). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP, RA and DHCPv4
On Mon, Jul 27, 2015 at 3:58 PM, Juliusz Chroboczek wrote: > During my quick talk on Wednesday, I mentioned that I had been pleasantly > surprised at the very clean interaction between the protocols: > > - HNCP redistributes assigned prefixes into the routing protocol; > - HNCP redistributes assigned prefixes into the RA and DHCPv4 servers; > - the routing protocol redistributes the default route into RA and DHCPv4. > > That's very elegant -- unless I've missed something, there are no other > cross-protocol interactions in the subset of the Homenet stack that is > implemented in shncpd. There is one thing I worry about with this strategy... if HNCP redistributes assigned prefixes into the RA/DHCPv4 servers, who makes sure that these are prefixes that are "reasonable good" measured by the metric of the routing protocol? Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] HNCP, RA and DHCPv4
During my quick talk on Wednesday, I mentioned that I had been pleasantly surprised at the very clean interaction between the protocols: - HNCP redistributes assigned prefixes into the routing protocol; - HNCP redistributes assigned prefixes into the RA and DHCPv4 servers; - the routing protocol redistributes the default route into RA and DHCPv4. That's very elegant -- unless I've missed something, there are no other cross-protocol interactions in the subset of the Homenet stack that is implemented in shncpd. Redistribution into RA happens pretty smoothly (I'm testing against dhcpcd, the most complete DHCPv4/RA/DHCPv6 client I could find). The main desirable feature of RA is that it is possible to switch between being a default router and not being one dynamically, just by sending a new RA with a zero/non-zero default router lifetime. Renumbering is not as smooth -- it appears to be impossible to remove a set of addresses wholesale, retracting a set of PIOs merely causes the old addresses to become deprecated. Since after a renumbering event we're no longer routing towards the retracted prefix, the client will need to timeout its TCP connections, and any UDP applications will need to rebind to the non-deprecated addresses (please check your NTP and BitTorrent clients). The situation with DHCPv4 is not as satisfactory. It is not possible to force the clients to either pick a different default router or to renew their lease (FORCERENEW is not useful). This means that DHCPv4 clients will be stuck with a non-functional address until they choose to renew. As Markus explained to me, this is mitigated by three factors: 1. since IPv4 addresses are NATed, IPv4 renumbering is not likely to happen; 2. since DHCPv4 is not a very noisy protocol, we can use very low renewal times; 3. Windows users have already been trained to reboot when something doesn't work as expected. I know there are DHCP and 6man/6ops people on this mailing list, any opinions on whether we're doing it wrong and whether updates to RA/DHCPv4 are desirable? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Jul 27, 2015, at 8:04 AM, Hemant Singh (shemant) wrote: > (a) A routing protocol to use on the wired link at home No. There are multiple links, some wired, some wireless. The whole point of homenet is to get past “the link” or “the wired link and the wireless link”. If we just wanted to handle “the link,” we already have an RFC that adequately addresses that use case. > (b) Whatever routing is used on the wired link should also support the lossy > wifi link in the home. No. There may be wifi links in the home used as transit links, and those have to work even if propagation is not 99.999%. > (c) An average home has one wifi link. No. > Based on the requirements above, I would use ISIS for (a) and configure a > static route to the wifi link to deal with (b). And you would have failed to address the problem that that homenet set out to solve. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
-Original Message- From: Margaret Cullen [mailto:mrculle...@gmail.com] On Behalf Of Margaret Cullen Sent: Monday, July 27, 2015 8:08 AM To: Hemant Singh (shemant) Cc: Pascal Thubert (pthubert); Ted Lemon; HOMENET; Terry Manderson; Gert Doering; Dino Farinacci; Mikael Abrahamsson Subject: Re: [homenet] Moving forward. >This depends on what you mean by "one wifi link". I think we expect homes to >continue to have guest and home wi-fi SSIDs, or equivalent. I don't know >whether this will >continue to be provided at layer 2, or whether homenet >prefix delegation would allow these links to be routed, instead of bridged. >Also, I think we expect homes to potentially >have other types of wireless >links (i.e. IEEE 802.16). One SSID. I agree two SSIDs are also possible and so is 802.16. So now one has several wireless links which are lossy. Thanks, Hemant ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
> (c) An average home has one wifi link. Many home routers have three wireless links (2.4GHz, 5GHz, and guest). This will only get more common with 802.11ac. > Any other requirements or changes to the above text? Many would prefer a routing protocol with a well-defined, self-contained specification that can be implemented in finite time. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
Hi, there is also the point that "wifi repeaters" are quite stupid devices at the moment. I could see "Homenet wifi extenders" which just are Homenet routers with multiple wifi interfaces routing traffic between them. Henning Rogge On Mon, Jul 27, 2015 at 2:12 PM, Jonathan Hansford wrote: > Was in the process of asking the same question about "one wifi link". I > don't think my homenet is "average", but I have the wifi router and two > APs, > each has its own SSID for static devices, and share one home SSID and one > Guest SSID for more mobile devices. > > Jonathan > > > -Original Message- > > From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Margaret > > Cullen > > Sent: 27 July 2015 13:08 > > To: Hemant Singh (shemant) > > Cc: Pascal Thubert (pthubert) ; Ted Lemon > > ; Dino Farinacci ; HOMENET > > ; Mikael Abrahamsson ; Gert > > Doering ; Terry Manderson > > Subject: Re: [homenet] Moving forward. > > > > > > On Jul 27, 2015, at 8:04 AM, "Hemant Singh (shemant)" > > wrote: > > > (c) An average home has one wifi link. > > > > > > Any other requirements or changes to the above text? > > > > This depends on what you mean by "one wifi link". I think we expect > homes > > to continue to have guest and home wi-fi SSIDs, or equivalent. I don't > know > > whether this will continue to be provided at layer 2, or whether homenet > > prefix delegation would allow these links to be routed, instead of > bridged. > > Also, I think we expect homes to potentially have other types of wireless > > links (i.e. IEEE 802.16). > > > > Margaret > > > > > > ___ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
Was in the process of asking the same question about "one wifi link". I don't think my homenet is "average", but I have the wifi router and two APs, each has its own SSID for static devices, and share one home SSID and one Guest SSID for more mobile devices. Jonathan > -Original Message- > From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Margaret > Cullen > Sent: 27 July 2015 13:08 > To: Hemant Singh (shemant) > Cc: Pascal Thubert (pthubert) ; Ted Lemon > ; Dino Farinacci ; HOMENET > ; Mikael Abrahamsson ; Gert > Doering ; Terry Manderson > Subject: Re: [homenet] Moving forward. > > > On Jul 27, 2015, at 8:04 AM, "Hemant Singh (shemant)" > wrote: > > (c) An average home has one wifi link. > > > > Any other requirements or changes to the above text? > > This depends on what you mean by "one wifi link". I think we expect homes > to continue to have guest and home wi-fi SSIDs, or equivalent. I don't know > whether this will continue to be provided at layer 2, or whether homenet > prefix delegation would allow these links to be routed, instead of bridged. > Also, I think we expect homes to potentially have other types of wireless > links (i.e. IEEE 802.16). > > Margaret > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
Hi, On Mon, Jul 27, 2015 at 12:04:28PM +, Hemant Singh (shemant) wrote: > Based on the requirements above, I would use ISIS for (a) and configure a > static route to the wifi link to deal with (b). "If all you have is a hammer, every problem looks like a nail" Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgp06enY_mTdc.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Jul 27, 2015, at 8:04 AM, "Hemant Singh (shemant)" wrote: > (c) An average home has one wifi link. > > Any other requirements or changes to the above text? This depends on what you mean by "one wifi link". I think we expect homes to continue to have guest and home wi-fi SSIDs, or equivalent. I don't know whether this will continue to be provided at layer 2, or whether homenet prefix delegation would allow these links to be routed, instead of bridged. Also, I think we expect homes to potentially have other types of wireless links (i.e. IEEE 802.16). Margaret ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
I agree with Pascal. Thrashing for few years is not good. Just publish a short document for what the homenet routing requirements are and then let the IETF routing WG look into the issue. So far, having worked with Ted privately, I see the requirements are: (a) A routing protocol to use on the wired link at home (b) Whatever routing is used on the wired link should also support the lossy wifi link in the home. (c) An average home has one wifi link. Any other requirements or changes to the above text? Based on the requirements above, I would use ISIS for (a) and configure a static route to the wifi link to deal with (b). Hemant -Original Message- From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Sunday, July 26, 2015 3:18 PM To: Ted Lemon Cc: HOMENET; Mikael Abrahamsson; Gert Doering; Dino Farinacci; Terry Manderson Subject: Re: [homenet] Moving forward. Hello Ted: Seems that there's more work than what we can expect from a DT. Otherwise we'd be all set by now. What about forming a flash WG in routing area to see if: - we can extract requirements for home - there's such a thing as a one size fits all homes routing protocol - provide recommendations on how to use (a combination of) existing standards, and, if that can not be done,whether a new protocol is needed ROLL followed that path. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Babel Mailing List
A new mailing list, ba...@ietf.org, has been established to discuss the Babel Routing Protocol, including how/if we might standardize Babel within the IETF. The Babel Routing Protocol is documented in an experimental RFC (https://tools.ietf.org/html/rfc6126), and Juliusz Chroboczek presented an overview of Babel during an informal session at IETF 93. His slides can be found here: http://www.pps.univ-paris-diderot.fr/~jch/software/babel/babel-20150723.pdf). You can subscribe to this list using the following URL: https://www.ietf.org/mailman/listinfo/babel Alternatively, you can subscribe by sending a message to babel-requ...@ietf.org with the word subscribe in the header. No one has been subscribed automatically, so if you intend to follow this discussion, please subscribe. Thanks, Margaret ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Mon, Jul 27, 2015 at 11:59 AM, Juliusz Chroboczek < j...@pps.univ-paris-diderot.fr> wrote: > Whatever happens within Homenet, it's good to hear that we've managed to > put dynamically computed, unstable metrics on the radar for at least some > IETF insiders. > > The exchange of ideas is also happening in the other direction -- Matthieu > and I are going to Battlemesh next week, and we'll be trying to sell the > idea of source-specific routing to the community mesh people. (Henning > is telling me that he already has an implementation of source-specific > routing for OLSRv2, he'll hopefully demo it at Battlemesh.) The code itself is working (I tested it with Teco Boot during the IETF), I just have to resolve the detection of routers that cannot do source-specific routing. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
> yes, sure, IS-IS is great. It does a lot. It would almost certainly work > very nicely in homenet. However, it lacks a feature that the working group > agreed we needed: support for wireless transit networks that might be > lossy. This feature could be added, but is not yet present. Whatever happens within Homenet, it's good to hear that we've managed to put dynamically computed, unstable metrics on the radar for at least some IETF insiders. The exchange of ideas is also happening in the other direction -- Matthieu and I are going to Battlemesh next week, and we'll be trying to sell the idea of source-specific routing to the community mesh people. (Henning is telling me that he already has an implementation of source-specific routing for OLSRv2, he'll hopefully demo it at Battlemesh.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Babel side-meeting slides
Hi, The slides from last Thursday's side-meeting are at http://www.pps.univ-paris-diderot.fr/~jch/software/babel/babel-20150723.pdf There are a few typos and a few slides that are a little overloaded, but altogether they look correct to me. Please send questions to me personally or to since I'd rather we didn't go through the somewhat sterile routing protocol discussion on this list again. Thanks, -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
Hi, On Sun, Jul 26, 2015 at 07:18:14PM +, Pascal Thubert (pthubert) wrote: > What about forming a flash WG in routing area to see if: [..] I really wonder if this is is about "getting anywhere" any longer, or whether we should just form a few subcommittees that decide on task forces to establish temporary WGs to decide on the proper naming of some other working group drafts instead. I've done testing with babels-based openwrt HNCP implementation over a year ago(!), and while that code had warts, it actually worked well for my tests. Instead on just agreeing on "working code is good, let's write it up!" this working group is now even further away from actually agreeing on anything that could lead to a shipping product based on an actual *standard*... So, folks, what is that you *want*? "See your favourite routing protocol win, no matter what the cost" or "produce something that can be implemented by a chinese garage shop (... by taking one of the two existing and well- tested open source implementations, slapping a new label on it, and shipping it)"? Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgplpEpdcukXX.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
