Re: [homenet] routing protocol comparison document and hncp
On Mar 2, 2015, at 7:32 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: In message 7615609f-512e-42aa-a2e7-4dbb31f1a...@chopps.org Christian Hopps writes: Hi homenet-wg, One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? Thanks, Chris. Chris, Yes. I agree. And OSPF could do the same, without dragging CLNP in with it. Using CLNP framing for IS-IS packets at the L2 layer is not the same as dragging in CLNP. No homenet router is going to do anything with ISO like frames other than drop them or hand them off to IS-IS. Maybe ISIS-WG should consider an ISIS-over-IP draft? I actually presented that draft back in 1999, it was my first presentation at IETF; it didn’t go anywhere. :) Chris. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/03/2015 05:55 AM, David Oran wrote: On Mar 2, 2015, at 9:05 PM, Michael Thomas m...@mtcc.com wrote: On 03/02/2015 01:21 PM, Brian E Carpenter wrote: On 03/03/2015 09:12, Michael Thomas wrote: I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Well, I want certificates, because I don't believe someone who says Hi, I'm your friendly homenet router and here's my public key. so you're mollified if somebody's cert says hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx instead? Actually, I’m suspicious, which is entirely appropriate. If, on the other hand, the cert says router3.orandom.net and orandom.net is my domain with delegated DNSSEC from my domain provider I might be a tad more trusting than if I just saw a 2048bit raw public key. Considering that provisioning personal certificates is the almost the polar opposite of zeroconf, the chances of the normal schlub seeing an informative and/or trustworthy name are really, really low. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi, On Tue, Mar 03, 2015 at 07:31:56AM -0800, Michael Thomas wrote: Considering that provisioning personal certificates is the almost the polar opposite of zeroconf, the chances of the normal schlub seeing an informative and/or trustworthy name are really, really low. You might want to entertain you reading draft-behringer-homenet-trust-bootstrap which gives a good idea how this could work (the general ideas, maybe not the specific implementation). Of course the normal end user is not going to ever look at or manually generate a certificate. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your normal authentication scheme. Obviously, would be nice if protocol supported certs directly, but it’s not required. IKE provides just symmetric crypto key between two parties. Typical network has more (and routing protocols use multicast). Multiparty IKE is more or less dead (or undead?). Remember, we need whole network to agree on the keys, or at least everyone on the link if any multicast is used in a way that requires authentication or confidentiality. (HNCP is designed to avoid transmitting anything important over multicast; are routing protocols? For most part, I think not.) Sorry, I haven't been following all this discussion so I may be missing something, but ... I would say: Pick a master (on a link, or the entire network); master calculates a random key; distributes it to the other nodes using asymmetric crypto; all nodes use that key. For rollover use some key chain mechanism such that for a period of time old and new key are accepted. Plug those keys into the normal routing protocol security mechanism. What am I missing? Michael ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On Mar 2, 2015, at 9:05 PM, Michael Thomas m...@mtcc.com wrote: On 03/02/2015 01:21 PM, Brian E Carpenter wrote: On 03/03/2015 09:12, Michael Thomas wrote: I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Well, I want certificates, because I don't believe someone who says Hi, I'm your friendly homenet router and here's my public key. so you're mollified if somebody's cert says hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx instead? Actually, I’m suspicious, which is entirely appropriate. If, on the other hand, the cert says router3.orandom.net and orandom.net is my domain with delegated DNSSEC from my domain provider I might be a tad more trusting than if I just saw a 2048bit raw public key. the possession of a cert does nothing in and of itself to make an enrollment decision. I agree that the cert itself does nothing. The name in the cert, as long as it isn’t self signed, provides a trust anchor. Mike ___ 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] routing protocol comparison document and hncp
Hi, On Mon, Mar 02, 2015 at 07:48:24PM -0500, Curtis Villamizar wrote: The way IETF has normally done things is to allow multiple developments to exist if they have support and then drop only those that are not being deployed or prove to be less desirable. Having multiple examples of running code is certainly a good thing. Discussing all potential approaches to death, unless the committee has won, and the result is an unimplementable nightmare of myriads of different options is what IETF WGs have changed to in more recent years - and if I look at the last few rounds of discussions, I can certainly understand why Dave moved off to get something *done*. A: here's a draft that got implemented, works, and needs feedback but I want ISIS! and I want OSPF! goto A gert, tempted to call it a day and spend my time *deploying* IPv6 somewhere -- 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/03/2015 09:12, Michael Thomas wrote: On 03/02/2015 11:54 AM, Brian E Carpenter wrote: On 03/03/2015 08:38, Michael Thomas wrote: Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your normal authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Well, I want certificates, because I don't believe someone who says Hi, I'm your friendly homenet router and here's my public key. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 2.3.2015, at 21.34, Michael Behringer (mbehring) mbehr...@cisco.com wrote: Then one can always discuss what kind of information could go into each protocol after bootstrap. Perhaps what we actually need is a new bootstrap security protocol (not only for homenet), and that this is where the emphasis should be. Possibly. However, even if we had one, bootstrap protocol does not lead easily to widely shared PSKs, and that’s what routing protocols require. E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I had a certificate, I am not sure how it helps with PSK IS-IS scheme. Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your normal authentication scheme. Obviously, would be nice if protocol supported certs directly, but it’s not required. IKE provides just symmetric crypto key between two parties. Typical network has more (and routing protocols use multicast). Multiparty IKE is more or less dead (or undead?). Remember, we need whole network to agree on the keys, or at least everyone on the link if any multicast is used in a way that requires authentication or confidentiality. (HNCP is designed to avoid transmitting anything important over multicast; are routing protocols? For most part, I think not.) I might be wrong, hopefully some points me at some asymmetric crypto enabled multi-party authentication method for _some_ routing protocol.. Only way I could imagine this working is by firing up metric shitload of on-demand (e.g. GRE) tunnels on top of IPsec (based on some yet undefined on-link peer detection scheme), then running some RP over them in p2p mode. Then we realize that all security needed is really in the peer-detection (which can be conservative, very rate limited and so on) and the IPsec, and we would require no security features from the routing protocol itself. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. It is relatively heavy in terms of number of protocols to the functionality I would want, but I agree that on the paper[1] it does what it advertises it does, but it is not enough to make routing protocols work in and of itself, see above. Cheers, -Markus [1] I have yet to see an implementation; I have heard one exists. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/02/2015 01:21 PM, Brian E Carpenter wrote: On 03/03/2015 09:12, Michael Thomas wrote: I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Well, I want certificates, because I don't believe someone who says Hi, I'm your friendly homenet router and here's my public key. so you're mollified if somebody's cert says hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx instead? the possession of a cert does nothing in and of itself to make an enrollment decision. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi Curtis, The main reason for going forward with IS-IS over OSPFv3 is that there was an open source implementation willing to implement and support all the enhancements necessary for Homenet. Admittedly, the source/destination routing requirement makes the entrance barrier a bit higher for OSPFv3 than other protocols. The reason for this is that it requires the implementation of http://www.ietf.org/id/draft-ietf-ospf-ospfv3-lsa-extend-06.txt in order to support fully extendable LSAs. Hopefully, we can get some implementation momentum for OSPFv3 Extendable LSAs this year. If not soon, I have an idea for a cheaper, yet less elegant approach. Thanks, Acee On 3/2/15, 7:32 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: In message 7615609f-512e-42aa-a2e7-4dbb31f1a...@chopps.org Christian Hopps writes: Hi homenet-wg, One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? Thanks, Chris. Chris, Yes. I agree. And OSPF could do the same, without dragging CLNP in with it. Maybe ISIS-WG should consider an ISIS-over-IP draft? Oh wait - non-routability of CLNP is a security feature - so don't forget to mention that in the security section. You might need providers to use filters at borders and GTSM as they do for OSPF. Curtis ___ 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] routing protocol comparison document and hncp
Regards Brian Carpenter http://orcid.org/-0001-7924-6182 On 03/03/2015 15:05, Michael Thomas wrote: On 03/02/2015 01:21 PM, Brian E Carpenter wrote: On 03/03/2015 09:12, Michael Thomas wrote: I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Well, I want certificates, because I don't believe someone who says Hi, I'm your friendly homenet router and here's my public key. so you're mollified if somebody's cert says hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx instead? the possession of a cert does nothing in and of itself to make an enrollment decision. No, of course not. That is the whole point of using draft-pritikin-anima-bootstrapping-keyinfra or an equivalent. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/02/2015 06:50 PM, Brian E Carpenter wrote: so you're mollified if somebody's cert says hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx instead? the possession of a cert does nothing in and of itself to make an enrollment decision. No, of course not. That is the whole point of using draft-pritikin-anima-bootstrapping-keyinfra or an equivalent. The point being that enrollment decisions have very little to do with the name binding claimed by some third party, especially when the name binding itself in a zero/littleconf most likely has little/no meaning to the enrollor (ie, mybrandnewrouter1...@china.com). It's hardly news that I'm biased against certs, but the biggest reason is that people impute in them superpowers which only get in the way of discussing the actual problems. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
In message c8e13842-f1d9-4768-86a7-3b2ea1e56...@chopps.org Christian Hopps writes: On Mar 2, 2015, at 8:00 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. I see that you've been speaking with Abrahamsson. Please let me give you some background. It's not just Mikael that has this opinion, he's just the more active email participant. If true should we be calling this out more explicitly in the document? I seem to recall that I already mentioned that I find your tendency to bring out controversial arguments just before a deadline somewhat offputting. There was nothing nefarious here. I just thought of a question and raised it. I think we should be open to doing that any time free of attack. Thanks, Chris. I agree with Chris. WGs are allowed to change their decisions particularly in early stages when there is no significant ***deployment***. Even then WGs can take a new direction but need to include backward compatibility or at least have a solid plan for (hopefully painless) transition. For example, MPLS started with RSVP-TE and CRLDP and years later dropped CRLDP due to lack of deployment. CIDR obsoleted EGP, BGP1-3, RIP1, and lots of other protocols, but there was a good reason and a clear transition plan. The way IETF has normally done things is to allow multiple developments to exist if they have support and then drop only those that are not being deployed or prove to be less desirable. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
In message 7615609f-512e-42aa-a2e7-4dbb31f1a...@chopps.org Christian Hopps writes: Hi homenet-wg, One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? Thanks, Chris. Chris, Yes. I agree. And OSPF could do the same, without dragging CLNP in with it. Maybe ISIS-WG should consider an ISIS-over-IP draft? Oh wait - non-routability of CLNP is a security feature - so don't forget to mention that in the security section. You might need providers to use filters at borders and GTSM as they do for OSPF. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
In message 87twy3wjtr.wl-...@pps.univ-paris-diderot.fr Juliusz Chroboczek writes: I got my hands on ISO 10589 today and tried to very briefly glance through it. And personally I had a really hard time getting into it. Having read the comparison document beforehand I haven't found anything about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the draft (and that ISO standard was ~200 pages already). You need RFC 1195, RFC 3719, RFC 3787, RFC 5304, RFC 5305, and RFC 5308. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet Hint: RFC 1195 does a better job explaining what ISIS does than ISO 10589. Read RFC 1195 first. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On Mar 2, 2015, at 9:07 AM, Steven Barth cy...@openwrt.org wrote: One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? I got my hands on ISO 10589 today and tried to very briefly glance through it. And personally I had a really hard time getting into it. Yes. ISO standards are not always the best place to get an overview of things. :) The document referred to here is ISO10589:2002. Section 6.8 is an overview IS-IS link-independent stuff. (pages 12-14) Section 7 gets into specifics but skip anything about level 2 (definitely skip partition repair), at least to start, as we are only considering level-1 single-area operation. Feel free to skip over (or quickly glance through) any address specific stuff (7.1) as it mostly does not pertain. Also skip anything related to hosts for now (ES or end-systems, i.e., ISO hosts). 7.2 The Decision Process (pages 18-26) This is basically an SPF with bi-directional checks (both sides of a link refer to each other). Additionally the fact that a broadcast network is treated as a pseudo-node with routers (non-pseudonodes) attached to it (rather than a full-mesh of connections between routers) is important. So 7.3 is the update process (advertising and flooding of information). (pages 26-45) Primarily this is going to get into - How a router advertises it’s information (LSP generation) - How IS-IS makes sure things are flooded (using sequence number packets and internally 2 flags called SRM and SSN). - LSP expiration and collision detection. Feel free to skip 7.4 (forwarding process), 7.5 (constants and parameters). Section 8 is the link dependent stuff. Here the hello protocol is documented. Skip ES (end-system stuff). - P2P (pages 50-54) - Skip 8xxx - Broadcast (pages 59-63) Section 9 documents the protocol (on-the-wire) encodings (page 65-92) Everything else can be skipped (page 92 on). Having read the comparison document beforehand I haven't found anything about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the draft (and that ISO standard was ~200 pages already). There’s a new version that has the references to the RFCs for v4, v6, hmac and wide metrics. The core of the IS-IS protocol is contained in about 80 pages. From above you should be able to get an good idea of the protocol in about ~40 pages, although it won’t necessarily be easy reading. :) So I think I asked Mikael the same thing already but could you (or anyone else) please provide a dumbed down specification or at least an overview document that references all relevant ISO-standards, RFCs and drafts (or chapters thereof) that one needs to read to understand modern IS-IS? On top of that if you could mention what could / or should be removed for a trimmed down homenet version that would be a huge plus. Basically a trimmed down version is level-1 operation only (everything in a single area). Whenever something mentioned level-2 operation discard it. Thanks, Chris. Cheers, Steven ___ 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] routing protocol comparison document and hncp
On 2.3.2015, at 15.55, Mikael Abrahamsson swm...@swm.pp.se wrote: On Mon, 2 Mar 2015, Margaret Wasserman wrote: I think Markus' comments on security are also very important to consider here, as some sort of integrated security mechanism between the routing protocol and HNCP might be strongly desired. Yes, I agree that HNCP has gained security that currently none of the routing protocols have, and that this is important. Then one can always discuss what kind of information could go into each protocol after bootstrap. Perhaps what we actually need is a new bootstrap security protocol (not only for homenet), and that this is where the emphasis should be. Possibly. However, even if we had one, bootstrap protocol does not lead easily to widely shared PSKs, and that’s what routing protocols require. E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I had a certificate, I am not sure how it helps with PSK IS-IS scheme. Babel + IKE + IPsec, on the other hand, could of course run with the certificate, but would not be link-state = hard to replicate state. Looking at fast adoption, perhaps OSPF would be preferable then, as it already runs over IP so the story would be just ’take TEH BOOTSTRAPPER, IKE, IPsec, OSPF’ and world is your oyster. No standardization required (beyond dst-src draft by Baker, just like IS-IS). Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
I got my hands on ISO 10589 today and tried to very briefly glance through it. And personally I had a really hard time getting into it. Having read the comparison document beforehand I haven't found anything about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the draft (and that ISO standard was ~200 pages already). You need RFC 1195, RFC 3719, RFC 3787, RFC 5304, RFC 5305, and RFC 5308. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 2.3.2015, at 15.00, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. I see that you've been speaking with Abrahamsson. Please let me give you some background. Two years ago, there was a very animated discussion about whether the configuration protocol and the routing protocol should be separate or not. After a lot of energy was spent on the issue, Markus designed HNCP, which went through a few iterations. The chairs judged that WG consensus was achieved, and the configuration protocol is now separate from the routing protocol. Since achieving consensus on this was a lot of work, some of us are somewhat annoyed at Mikael bringing this argument back from the dead at every opportunity. Funny part is, the argument has changed substantially since. Originally I considered HNCP security to be strictly optional, but as there was push-back to have built-in security, I added it in. And now it is essentially more littleconf’able than any routing protocol security scheme I have ever met before. The current draft specifies only PSK based security; do you really want to bootstrap your home security either with well-known ‘IamGoodguy’ password, or perhaps by logging in to every router to do magic things? No, me neither. I am looking forward to hearing some of some relatively dynamic security protocol (think IKE, or TLS handshake) that runs on top of CLNP though that we can hook in to IS-IS. The current draft’s ’security’ requirements for (stand-alone) use of either routing protocol’s own security framework are inadequate to what the group has been discussing here (among other places) over the last year. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. I see that you've been speaking with Abrahamsson. Please let me give you some background. Two years ago, there was a very animated discussion about whether the configuration protocol and the routing protocol should be separate or not. After a lot of energy was spent on the issue, Markus designed HNCP, which went through a few iterations. The chairs judged that WG consensus was achieved, and the configuration protocol is now separate from the routing protocol. Since achieving consensus on this was a lot of work, some of us are somewhat annoyed at Mikael bringing this argument back from the dead at every opportunity. If true should we be calling this out more explicitly in the document? I seem to recall that I already mentioned that I find your tendency to bring out controversial arguments just before a deadline somewhat offputting. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi, On Mon, Mar 02, 2015 at 07:33:47AM -0500, Christian Hopps wrote: One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? I'm sure we could, but what is it that the WG wants? - achieve something that vendors could deploy, in finite time - do another few rounds on protocols, variations, personal peeves, and end up with something like IPSEC? I'm firmly in the do something that is good enough, and get it deployed camp, which means no, we don't do everything-on-top-of-ISIS. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Thanks for the quick reply. Looks like I will be having something to read on the plane to Dallas. On 02.03.2015 15:56, Christian Hopps wrote: On Mar 2, 2015, at 9:07 AM, Steven Barth cy...@openwrt.org wrote: One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? I got my hands on ISO 10589 today and tried to very briefly glance through it. And personally I had a really hard time getting into it. Yes. ISO standards are not always the best place to get an overview of things. :) The document referred to here is ISO10589:2002. Section 6.8 is an overview IS-IS link-independent stuff. (pages 12-14) Section 7 gets into specifics but skip anything about level 2 (definitely skip partition repair), at least to start, as we are only considering level-1 single-area operation. Feel free to skip over (or quickly glance through) any address specific stuff (7.1) as it mostly does not pertain. Also skip anything related to hosts for now (ES or end-systems, i.e., ISO hosts). 7.2 The Decision Process (pages 18-26) This is basically an SPF with bi-directional checks (both sides of a link refer to each other). Additionally the fact that a broadcast network is treated as a pseudo-node with routers (non-pseudonodes) attached to it (rather than a full-mesh of connections between routers) is important. So 7.3 is the update process (advertising and flooding of information). (pages 26-45) Primarily this is going to get into - How a router advertises it’s information (LSP generation) - How IS-IS makes sure things are flooded (using sequence number packets and internally 2 flags called SRM and SSN). - LSP expiration and collision detection. Feel free to skip 7.4 (forwarding process), 7.5 (constants and parameters). Section 8 is the link dependent stuff. Here the hello protocol is documented. Skip ES (end-system stuff). - P2P (pages 50-54) - Skip 8xxx - Broadcast (pages 59-63) Section 9 documents the protocol (on-the-wire) encodings (page 65-92) Everything else can be skipped (page 92 on). Having read the comparison document beforehand I haven't found anything about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the draft (and that ISO standard was ~200 pages already). There’s a new version that has the references to the RFCs for v4, v6, hmac and wide metrics. The core of the IS-IS protocol is contained in about 80 pages. From above you should be able to get an good idea of the protocol in about ~40 pages, although it won’t necessarily be easy reading. :) So I think I asked Mikael the same thing already but could you (or anyone else) please provide a dumbed down specification or at least an overview document that references all relevant ISO-standards, RFCs and drafts (or chapters thereof) that one needs to read to understand modern IS-IS? On top of that if you could mention what could / or should be removed for a trimmed down homenet version that would be a huge plus. Basically a trimmed down version is level-1 operation only (everything in a single area). Whenever something mentioned level-2 operation discard it. Thanks, Chris. Cheers, Steven ___ 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] Routing protocol comparison document
On Fri, Feb 27, 2015 at 2:28 PM, Dave Taht dave.t...@gmail.com wrote: [...] The next version of cerowrt will do translation from the external IPv6 address range to a static internal one (or ones, in the case of multiple egress gateways), and lacking a standard for such will use fcxx/8 addressing. I will make it be an option for people to turn off, but I've had it with being renumbered. And so it begins. I am sure this will break stuff, and I don't know what all it will do, and I intend to find out. I'd prefer that we simply consider CeroWRT with this change to be fundamentally broken, and begin by keeping track of the things that still work with it, rather than what it breaks. Until some far off day where we have stable name to ipv6 address mapping, and vice versa, it is otherwise impossible to have useful ipv6 based services inside the home or small business. Doesn't seem impossible to me. Too difficult? I could agree with that, but I would have to say it's the ubiquitous RFC 6092 filters that are going to kill that idea before the frequent renumbering does. Seriously, people: we could give up on the IPv6 servers on home and small business networks thing any day now, and I don't think we would lose much steam. Given that those filters are everywhere and turned on by default in most cases, it's only just a little bit worse if home gateways are using NPTv6 too. It's not like you could use working address referral if you wanted. (p.s. I'm aware of at least one other serious proposal to use NPTv6 in a shipping home gateway. It would be easier to argue against it if those RFC 6092 filters weren't installed everywhere.) -- james woodyatt j...@nestlabs.com Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
If we carry NAT over to IPV6, then shame on us. I am sorry, I no longer share this opinion [...] The next version of cerowrt will do translation from the external IPv6 address range to a static internal one (or ones, in the case of multiple egress gateways), (Insert strong expression of disagreement here. Use any means available to convince Dave otherwise, including flattery, threats, demagoguery, ad hominem attacks and photographs of cute animals.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Mar 2, 2015, at 1:59 PM 3/2/15, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: If we carry NAT over to IPV6, then shame on us. I am sorry, I no longer share this opinion [...] The next version of cerowrt will do translation from the external IPv6 address range to a static internal one (or ones, in the case of multiple egress gateways), Are you at least following NPTv6, RFC 6296? (Insert strong expression of disagreement here. Use any means available to convince Dave otherwise, including flattery, threats, demagoguery, ad hominem attacks and photographs of cute animals.) Photographs of threats to cute animals? Don't code IPv6 address translation or the kitten gets it! -- 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] routing protocol comparison document and hncp
On 03/02/2015 11:34 AM, Michael Behringer (mbehring) wrote: -Original Message- From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Markus Stenberg Sent: 02 March 2015 15:11 To: Mikael Abrahamsson Cc: homenet@ietf.org; Markus Stenberg; Margaret Wasserman; Christian Hopps Subject: Re: [homenet] routing protocol comparison document and hncp On 2.3.2015, at 15.55, Mikael Abrahamsson swm...@swm.pp.se wrote: On Mon, 2 Mar 2015, Margaret Wasserman wrote: I think Markus' comments on security are also very important to consider here, as some sort of integrated security mechanism between the routing protocol and HNCP might be strongly desired. Yes, I agree that HNCP has gained security that currently none of the routing protocols have, and that this is important. Then one can always discuss what kind of information could go into each protocol after bootstrap. Perhaps what we actually need is a new bootstrap security protocol (not only for homenet), and that this is where the emphasis should be. Possibly. However, even if we had one, bootstrap protocol does not lead easily to widely shared PSKs, and that’s what routing protocols require. E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I had a certificate, I am not sure how it helps with PSK IS-IS scheme. Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your normal authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
-Original Message- From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Markus Stenberg Sent: 02 March 2015 15:11 To: Mikael Abrahamsson Cc: homenet@ietf.org; Markus Stenberg; Margaret Wasserman; Christian Hopps Subject: Re: [homenet] routing protocol comparison document and hncp On 2.3.2015, at 15.55, Mikael Abrahamsson swm...@swm.pp.se wrote: On Mon, 2 Mar 2015, Margaret Wasserman wrote: I think Markus' comments on security are also very important to consider here, as some sort of integrated security mechanism between the routing protocol and HNCP might be strongly desired. Yes, I agree that HNCP has gained security that currently none of the routing protocols have, and that this is important. Then one can always discuss what kind of information could go into each protocol after bootstrap. Perhaps what we actually need is a new bootstrap security protocol (not only for homenet), and that this is where the emphasis should be. Possibly. However, even if we had one, bootstrap protocol does not lead easily to widely shared PSKs, and that’s what routing protocols require. E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I had a certificate, I am not sure how it helps with PSK IS-IS scheme. Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your normal authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. Michael Babel + IKE + IPsec, on the other hand, could of course run with the certificate, but would not be link-state = hard to replicate state. Looking at fast adoption, perhaps OSPF would be preferable then, as it already runs over IP so the story would be just ’take TEH BOOTSTRAPPER, IKE, IPsec, OSPF’ and world is your oyster. No standardization required (beyond dst-src draft by Baker, just like IS-IS). Cheers, -Markus ___ 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] routing protocol comparison document and hncp
On 03/02/2015 11:54 AM, Brian E Carpenter wrote: On 03/03/2015 08:38, Michael Thomas wrote: Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your normal authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
In message caa93jw4tumfm_lvzkrx7ark2z+hwtw5jboenpvfejut4l9t...@mail.gmail.com Dave Taht writes: On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: In message 54ee258e.8060...@gmail.com Brian E Carpenter writes: On 26/02/2015 05:14, Mikael Abrahamsson wrote: On Wed, 25 Feb 2015, Ray Hunter wrote: That way the devices can roam at L3, without all of the nasty side effects of re-establishing TPC sessions, or updating dynamic naming services, or having to run an L2 overlay network everywhere, or having to support protocols that require a specialised partner in crime on the server side (mTCP, shim6 et al). It's my firm belief that we need to rid clients of IP address dependence for its sessions. Asking clients to participate in HNCP only addresses the problem where HNCP is used. Fixing this for real would reap benefits for devices moving between any kind of network, multiple providers, mobile/fixed etc. Violent agreement. This is not a homenet problem; it's an IP problem. In fact, it's exactly why IP addresses are considered harmful in some quarters. Trying to fix it just for homenet seems pointless. http://www.sigcomm.org/ccr/papers/2014/April/000.008 Brian Brian, Seriously - your paper may be overstating the problem. At least if we discount IPv4 and in doing so eliminate NAT we solve a lot of problems that never should have existed in the first place. If we carry NAT over to IPV6, then shame on us. I am sorry, I no longer share this opinion. The pains of renumbering someones entire home network every time the ISP feels like it, given the enormous number of devices I have encountered that don't handle it well, are just too much to bear. I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to ANSNET as part of the NSFNET decommissioning). Not by myself of course, but there were only a few of us on this. It wasn't all that bad and we had about 2,000 things to renumber in hundreds of locations, many of them not manned. Shell scripts and ksh (kerberized rsh, not the Korn shell) made it simpler. The worst was Cisco routers and various old DSU/CSU and other commercial stuff since you had to use expect scripts on their CLI rather than just something of the form ksh fqdn -l root ifconfig newaddr/mask alias People with root on their workstation that didn't give us acess were given notice. We used interface aliases and gradually took down the old aliases and subnet addresses. Nothing critical was affected. It took a day or two, then bake time, then less than a day to remove aliases. OTOH - Most homes can't run two prefixes for a week or two before taking the old prefix down. And lots of consumer devices don't do aliases. But now days there is DHCP which didn't exist then (and ICMPv6 RS/RA and SLAAC). Are you having problems with the provider not giving you a static IPv6 prefix, but rather changing it on a whim? I also renumbered my home net multiple times, but again, not much pain. Only a few consumer gadgets here have fixed addresses (one because it never renewed DHCP leases and therefore needed a fixed address, but that has since been tossed in e-waste recycling). The next version of cerowrt will do translation from the external IPv6 address range to a static internal one (or ones, in the case of multiple egress gateways), and lacking a standard for such will use fcxx/8 addressing. I will make it be an option for people to turn off, but I've had it with being renumbered. Are you suggesting that we add NAT to IPv6? [I ask with disbelief.] I would definitely be turning that off since I have a plenty big and very static IPv6 prefix. I also have a (tiny) static IPv4 prefix so I have no choice but to IPv4 NAT due to its tiny size. A better option might be to use something that switches over faster than a DHCP lease times of days. It seems that ICMPv6 RA can be sent with prefix prefix information TLV with valid lifetime and/or preferred valid lifetime of zero. This is in RFC 4861 on Page 55: - If the prefix is already present in the host's Prefix List as the result of a previously received advertisement, reset its invalidation timer to the Valid Lifetime value in the Prefix Information option. If the new Lifetime value is zero, time-out the prefix immediately (see Section 6.3.5). Would that help? Also, stateful DHCPv6 can invalidate leases (me thinks)? Maybe DHCPv4? Am I mistaken about that? I am sure this will break stuff, and I don't know what all it will do, and I intend to find out. Just breaks the end-to-end principle and requires rendezvous and all that ugliness. IMHO it would be better to send an immediate RA with a zero lifetime on the old prefix and a normal lifetime on the new prefix. If hosts don't do the right thing they are in violation of RFC 4861. OTOH, invalidating a DHCP lease
Re: [homenet] Routing protocol comparison document
In message 17359.1424897...@sandelman.ca Michael Richardson writes: Ray Hunter v6...@globis.net wrote: I agree that WiFi roaming is a problem that needs addressing in Homenet. Yes, but can we rule it out of scope for now? Can we agree that it's not strictly a routing problem, and that the set of solutions that we are considering could be used, and that we could also explain how to do something like automatically setup capwap using HNCP for discovery, but that we don't have the head-of-queue block on this item for now? -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- Perhaps consider it two problems, roaming within an administrative domain and roaming into another administrative doamin. The latter is harder to solve. Other than bridging all of the AP within an administrative domain, there is no way to support the former without at least some host change. As I mentioned before, I favor putting a /128 on the loopback and having the routers/APs forward to the interface address of the moment to that /128. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
I am glad, incidentally, that for the first time, this wg is considering some of the problems wifi has, and growing towards understanding them in more detail. I have long been working on finding answers to these deep, underlying problems - after first identifying some the major ones: https://www.youtube.com/watch?v=Wksh2DPHCDIfeature=youtu.be and proposing some solutions to the IEEE that still worked inside the standard (well, obsoleting part of 802.11e entirely) http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-1265-00-0wng-More-on-Bufferbloat.pdf and also proposing some deep changes for 802.11ax (the successor to ac). Work on getting some of that stuff done is proceeding - unfunded, by volunteers that care, in their spare time... (one major set of needed patches: minstrel-blues - coupled power and rate control - is out for review on the linux-wireless mailing list and it could used an acked-by because it is great and desperately needed. You don't need to transmit at the highest possible rate when you are right next to the AP, and vice versa) Finally, a few weeks ago, I convinced a major wifi testing house to actually start poking at one subset of the problem, which is multiple stations attempting to transmit at the same time. This test uses a single TCP flow each, 1 up, 1 down, and measures the latency. http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png This is on the latest and best 802.11ac hardware on the retail market, transmitting at the highest possible rate, to 4 stations, under lab conditions. Under load, you presently observe latencies of 50-1000ms, and jitter, same. They only achieved ~ 1/3 the rate of the base mac capability. They haven't tried lower rates, or added interference, nor mixed in multicast, nor tried WDS, or 802.11s, or added stations - any one of which can mess things up by another order or two or *more* of magnitude, I am awaiting further results from them, testing lower rates in particular. But I do hope that they eventually manage to duplicate the kinds of results I have obtained all over the world in conference centers, hotels, and apartment buildings, where the typical latencies I observe can be in the 3-6 second range, and bandwidth, below a few dozen k, at best. This sort of result should be concerning to the people that would like to bridge everything, use range extenders, transmit any multicast at all (and add in new forms of multicast, like nd/hnetd/babel/etc), or have hope that wifi can continue to work at all - in the face of adding lots and lots more (IoT) wifi clients - without some major work on how our APs and client chipsets work at a deep level. And thus, this is why I am not paying a whole lot of attention to the ietf anymore, and sinking more of my energies into finding ways to preserve and repair one of the coolest, most free-ing internet technologies that has has ever existed. And it is also sort of why I am running ethernet or homeplugs everywhere I must. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
In message 54ee258e.8060...@gmail.com Brian E Carpenter writes: On 26/02/2015 05:14, Mikael Abrahamsson wrote: On Wed, 25 Feb 2015, Ray Hunter wrote: That way the devices can roam at L3, without all of the nasty side effects of re-establishing TPC sessions, or updating dynamic naming services, or having to run an L2 overlay network everywhere, or having to support protocols that require a specialised partner in crime on the server side (mTCP, shim6 et al). It's my firm belief that we need to rid clients of IP address dependence for its sessions. Asking clients to participate in HNCP only addresses the problem where HNCP is used. Fixing this for real would reap benefits for devices moving between any kind of network, multiple providers, mobile/fixed etc. Violent agreement. This is not a homenet problem; it's an IP problem. In fact, it's exactly why IP addresses are considered harmful in some quarters. Trying to fix it just for homenet seems pointless. http://www.sigcomm.org/ccr/papers/2014/April/000.008 Brian Brian, Seriously - your paper may be overstating the problem. At least if we discount IPv4 and in doing so eliminate NAT we solve a lot of problems that never should have existed in the first place. If we carry NAT over to IPV6, then shame on us. If we get rid of NAT a big part of the problem just goes away. No alternate spaces, kludgy rendezvous mechanisms, etc. Using an address on the loopback gets rid of the multiple interface problem and where it really matters (ISP router and ISP or DS server reachability) this has been done with configuration for two decades. The multihoming failover or roaming are a bit more difficult but things MPTCP is supposed to address. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: In message 54ee258e.8060...@gmail.com Brian E Carpenter writes: On 26/02/2015 05:14, Mikael Abrahamsson wrote: On Wed, 25 Feb 2015, Ray Hunter wrote: That way the devices can roam at L3, without all of the nasty side effects of re-establishing TPC sessions, or updating dynamic naming services, or having to run an L2 overlay network everywhere, or having to support protocols that require a specialised partner in crime on the server side (mTCP, shim6 et al). It's my firm belief that we need to rid clients of IP address dependence for its sessions. Asking clients to participate in HNCP only addresses the problem where HNCP is used. Fixing this for real would reap benefits for devices moving between any kind of network, multiple providers, mobile/fixed etc. Violent agreement. This is not a homenet problem; it's an IP problem. In fact, it's exactly why IP addresses are considered harmful in some quarters. Trying to fix it just for homenet seems pointless. http://www.sigcomm.org/ccr/papers/2014/April/000.008 Brian Brian, Seriously - your paper may be overstating the problem. At least if we discount IPv4 and in doing so eliminate NAT we solve a lot of problems that never should have existed in the first place. If we carry NAT over to IPV6, then shame on us. I am sorry, I no longer share this opinion. The pains of renumbering someones entire home network every time the ISP feels like it, given the enormous number of devices I have encountered that don't handle it well, are just too much to bear. The next version of cerowrt will do translation from the external IPv6 address range to a static internal one (or ones, in the case of multiple egress gateways), and lacking a standard for such will use fcxx/8 addressing. I will make it be an option for people to turn off, but I've had it with being renumbered. I am sure this will break stuff, and I don't know what all it will do, and I intend to find out. Until some far off day where we have stable name to ipv6 address mapping, and vice versa, it is otherwise impossible to have useful ipv6 based services inside the home or small business. If we get rid of NAT a big part of the problem just goes away. No alternate spaces, kludgy rendezvous mechanisms, etc. Using an address on the loopback gets rid of the multiple interface problem and where it really matters (ISP router and ISP or DS server reachability) this has been done with configuration for two decades. The multihoming failover or roaming are a bit more difficult but things MPTCP is supposed to address. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
When performance in dual stack networks with multiple WiFi AP's in homes suffers from homenet protocols, this WG produces dead protocols. Why would homenet cause wifi APs to suffer more than they do today? I think Teco was reacting to the suggestion that we perform wifi-wifi bridging at a larger scale that is done today. We'd need to actually try it out and perform some serious measurements in order to be sure (no, I'm not volunteering), but I'd expect it to suck, for at least the following reasons: 1. 802.11 bridging is weird, there are some restrictions on the possible topologies (but I don't recall the exact details). 2. I'd expect broadcast/multicast to be fun, especially if the different APs are set up to interfere. 3. Things like TRILL aside, bridging performs spanning tree routing, so unless you design your topology carefully, you have a good chance of pushing all of your traffic through a slow link. Never mind avoiding self-interference. I've already expressed my opinion (sometimes way too strongly, sorry Ted) that I'm opposed to reliance on L2 bridging until somebody shows how it can be made to work with good performance in a hybrid network. The 802.11s experience doesn't encourage us to be optimistic. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Thu, Feb 26, 2015 at 1:28 PM, Teco Boot t...@inf-net.nl wrote: Op 25 feb. 2015, om 22:00 heeft Mark Townsley m...@townsley.net het volgende geschreven: On Feb 25, 2015, at 9:50 PM, Michael Richardson mcr+i...@sandelman.ca wrote: Ray Hunter v6...@globis.net wrote: I agree that WiFi roaming is a problem that needs addressing in Homenet. Yes, but can we rule it out of scope for now? Yes, we can. I think the WG needs to focus on securing success before taking on wild success at this moment in time. When performance in dual stack networks with multiple WiFi AP's in homes suffers from homenet protocols, this WG produces dead protocols. Why would homenet cause wifi APs to suffer more than they do today? Worst case, wifi remains a single bridged dual-stack LAN. Best case, routing is possible and hosts are resilient to IP address changes. Somewhere in between HNCP helps with auto-configuration in one way or another. I don't see how the status quo path we are without Homenet can be worse with Homenet (separating out here whatever overhead of getting homenet itself deployed). I am more hopeful. I hope we can enable 802.11 fast handover by distributing the required info. Still open question how to route or bridge over the wired backbone. certainly do not want to inhibit your hope in anyway. Indeed, history shows that we successful protocols are often deployed in ways the designers do not expect. Just trying to nudge the group towards a bit more focus in order to ship sooner rather than later. - Mark Teco - Mark Can we agree that it's not strictly a routing problem, and that the set of solutions that we are considering could be used, and that we could also explain how to do something like automatically setup capwap using HNCP for discovery, but that we don't have the head-of-queue block on this item for now? -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- ___ 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] Routing protocol comparison document
Op 25 feb. 2015, om 22:00 heeft Mark Townsley m...@townsley.net het volgende geschreven: On Feb 25, 2015, at 9:50 PM, Michael Richardson mcr+i...@sandelman.ca wrote: Ray Hunter v6...@globis.net wrote: I agree that WiFi roaming is a problem that needs addressing in Homenet. Yes, but can we rule it out of scope for now? Yes, we can. I think the WG needs to focus on securing success before taking on wild success at this moment in time. When performance in dual stack networks with multiple WiFi AP's in homes suffers from homenet protocols, this WG produces dead protocols. I am more hopeful. I hope we can enable 802.11 fast handover by distributing the required info. Still open question how to route or bridge over the wired backbone. Teco - Mark Can we agree that it's not strictly a routing problem, and that the set of solutions that we are considering could be used, and that we could also explain how to do something like automatically setup capwap using HNCP for discovery, but that we don't have the head-of-queue block on this item for now? -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- ___ 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] Routing protocol comparison document
Op 26 feb. 2015, om 13:56 heeft Mark Townsley m...@townsley.net het volgende geschreven: On Thu, Feb 26, 2015 at 1:28 PM, Teco Boot t...@inf-net.nl wrote: Op 25 feb. 2015, om 22:00 heeft Mark Townsley m...@townsley.net het volgende geschreven: On Feb 25, 2015, at 9:50 PM, Michael Richardson mcr+i...@sandelman.ca wrote: Ray Hunter v6...@globis.net wrote: I agree that WiFi roaming is a problem that needs addressing in Homenet. Yes, but can we rule it out of scope for now? Yes, we can. I think the WG needs to focus on securing success before taking on wild success at this moment in time. When performance in dual stack networks with multiple WiFi AP's in homes suffers from homenet protocols, this WG produces dead protocols. Why would homenet cause wifi APs to suffer more than they do today? Worst case, wifi remains a single bridged dual-stack LAN. Best case, routing is possible and hosts are resilient to IP address changes. Somewhere in between HNCP helps with auto-configuration in one way or another. I don't see how the status quo path we are without Homenet can be worse with Homenet (separating out here whatever overhead of getting homenet itself deployed). Today's WiFi stacks typically prefer staying on connected SSID, until the link is really bad and breaks. Then the alternative SSID is selected, IP address is flushed and a new IP address is requested. This takes time. Connections break. Staying on the same SSID has advantages: IP address survives handover so connections continue to work. Also smarter handover can take place, this eliminates the bad link. So my opinion is that the homenet protocols shall be able to support a layer-2 backbone over a wired backbone connecting a set of access points. Or provide an alternative that works well over a layer-3 backbone. I'm all ears. Teco I am more hopeful. I hope we can enable 802.11 fast handover by distributing the required info. Still open question how to route or bridge over the wired backbone. certainly do not want to inhibit your hope in anyway. Indeed, history shows that we successful protocols are often deployed in ways the designers do not expect. Just trying to nudge the group towards a bit more focus in order to ship sooner rather than later. - Mark Teco - Mark Can we agree that it's not strictly a routing problem, and that the set of solutions that we are considering could be used, and that we could also explain how to do something like automatically setup capwap using HNCP for discovery, but that we don't have the head-of-queue block on this item for now? -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- ___ 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] Routing protocol comparison document
On 26/02/2015 05:14, Mikael Abrahamsson wrote: On Wed, 25 Feb 2015, Ray Hunter wrote: That way the devices can roam at L3, without all of the nasty side effects of re-establishing TPC sessions, or updating dynamic naming services, or having to run an L2 overlay network everywhere, or having to support protocols that require a specialised partner in crime on the server side (mTCP, shim6 et al). It's my firm belief that we need to rid clients of IP address dependence for its sessions. Asking clients to participate in HNCP only addresses the problem where HNCP is used. Fixing this for real would reap benefits for devices moving between any kind of network, multiple providers, mobile/fixed etc. Violent agreement. This is not a homenet problem; it's an IP problem. In fact, it's exactly why IP addresses are considered harmful in some quarters. Trying to fix it just for homenet seems pointless. http://www.sigcomm.org/ccr/papers/2014/April/000.008 Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 25, 2015, at 9:50 PM, Michael Richardson mcr+i...@sandelman.ca wrote: Ray Hunter v6...@globis.net wrote: I agree that WiFi roaming is a problem that needs addressing in Homenet. Yes, but can we rule it out of scope for now? Yes, we can. I think the WG needs to focus on securing success before taking on wild success at this moment in time. - Mark Can we agree that it's not strictly a routing problem, and that the set of solutions that we are considering could be used, and that we could also explain how to do something like automatically setup capwap using HNCP for discovery, but that we don't have the head-of-queue block on this item for now? -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- ___ 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] Routing protocol comparison document
So assuming some decent high-power 802.11ac in the Bradford house (http://en.wikipedia.org/wiki/Eight_Is_Enough) to link the per-room router to legacy 802.11b and per-person (phone) router to BTLE/PAN, it means we have about 30 routers on the wifi. I'm under opposing pressures relating to scaling. A lot of people, like you, seem to think it's irrelevant, some others feel very strongly about it. The current version of the draft has this to say: Experts appear to disagree on the expected size of a Homenet: we have heard estimates ranging from just one router up to 250 routers. In any case, while scaling beyond a few thousand nodes is not likely to be relevant to Homenet in the foreseeable future, the Homenet protocols, if successful, will be repurposed to larger networks, whether we like it or not, and it is desirable to use a protocol that scales well. The thinking is that if Homenet routers are cheaply and widely available, then people will use them for larger deployments; no amount of legislating such uses out of scope will change that fact. The obvious example would be a hotel: why pay for a professionally installed network when you can just plug in a bunch of $40 Homenet routers and be done with your customer network. I can well imagine a hotel using 200 routers. If hotels don't meet your fancy -- think schools, think appartment blocks in third world countries, think hippy communes. Do we wish to explicitly support such use cases? Hopefully not. But do we wish to have our protocols collapse just because we didn't have the foresight to avoid gratuitious limitations? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Hi Michael, The work on the document is being done on https://github.com/choppsv1 and I try to keep an up-to-date version of the generated files on http://www.pps.univ-paris-diderot.fr/~jch/private/draft-mrw-homenet-rtg-comparison-XX.html http://www.pps.univ-paris-diderot.fr/~jch/private/draft-mrw-homenet-rtg-comparison-XX.txt So the gateway machine (the 6LBR) will run the HOMENET routing protocol and the LLN routing protocol (RPL, or some other mesh-under protocol), but the HOMENET routing protocol will never be run by the sensors. I've vastly expanded the section about stub networks; please check if it suits you better or whether you wish anything added. It also, btw, makes it unable to run over 15.4, Noted, will add. 3) metrics. We don't know how we will assign link metrics, so we don't know how important X-bit metrics are. I've expanded the section about metrics. The IS-IS part is still woefully inadequate. 4) convergence over 802.11 MAC... I've expanded this section. 5) some amount of my processor is slower than yours and still ran protocol XYZ (http://www.phespirit.info/montypython/four_yorkshiremen.htm) Not my choice, sorry. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: So assuming some decent high-power 802.11ac in the Bradford house (http://en.wikipedia.org/wiki/Eight_Is_Enough) to link the per-room router to legacy 802.11b and per-person (phone) router to BTLE/PAN, it means we have about 30 routers on the wifi. I'm under opposing pressures relating to scaling. A lot of people, like you, seem to think it's irrelevant, some others feel very strongly about it. I'm not claiming its irrelevant, I'm claiming that it won't bite us all at once. I accept that some homenet-type installations will go up to 250 routers (which is only 1 order of magnitude larger than 30, btw), but they won't go up to 250 without some thought about it. So I totally agree with you: The thinking is that if Homenet routers are cheaply and widely available, then people will use them for larger deployments; no amount of legislating such uses out of scope will change that fact. The obvious example would be a hotel: why pay for a professionally installed network when you can just plug in a bunch of $40 Homenet routers and be done with your customer network. I can well imagine a hotel using 200 routers. but, what I'm claiming is that the 200 routers won't be in a single wifi channel.The network will get a small amount of tuning, if only because the walls will get in the way and some people will have to run some cables in places. That's exactly what most of think: that to scale things we need wired back hauls, so while we hit 250 routers in the routing table, we don't have to accomodate 250 routers forming adjacencies on a single wifi channel. If hotels don't meet your fancy -- think schools, think appartment blocks in third world countries, think hippy communes. Do we wish to explicitly support such use cases? Hopefully not. But do we wish to have our protocols collapse just because we didn't have the foresight to avoid gratuitious limitations? So, there are limitations like: struct router all_the_routers[256]; and then there are protocol collapses due to taking the entire channel for adjacencies as happened with OLPC. The trickle mechanism of DNCP ought to deal with that. What we need to do is to make sure that whatever parameters we pick for scaling fail in a safe way when exceeded. I'd rather that the router which has HomeNet v1 parameters in it just stops when it reaches some limit rather than cause congestion collapse. The router will then get replaced (or better, reflashed), but if not, it won't get in the way of the newer, better tuned devices. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
So, there are limitations like: struct router all_the_routers[256]; and then there are protocol collapses due to taking the entire channel for adjacencies as happened with OLPC. We're in full agreement about most of what you say. Are you happy with the current wording, or are you suggesting I change something? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On 2/19/15 9:22 AM, Juliusz Chroboczek wrote: smart rate limiting. ISIS already has these kinds of rate-limiting of how things are happening. In modern core routers this is often tuned If you need to tune it, it's not smart enough. To be fair, network operators have somewhat different priorities, e.g. rapid convergence at the expense of cpu may be ok, no effective bandwidth constraints when you're talking about an igp running on a gig or 10 gig point-to-point link... -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet signature.asc Description: OpenPGP digital signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
ISIS already has these kinds of rate-limiting of how things are happening. In modern core routers this is often tuned If you need to tune it, it's not smart enough. To be fair, network operators have somewhat different priorities, Yes, that was a cheap shot. Sorry, I couldn't resist. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
{my comments before reading the ~170 messages on this thread.}
comparison [Isn't it also the case that the HOMENET routing protocol will
comparison be implemented on lower-end embedded devices, such as nodes in
comparison a low-power wireless network? What is considered to be a
comparison reasonable low-end system requirement for a HOMENET router? --
comparison mrw]
As specified in the architecture document, section 3.5.1:
rfc7368 In this homenet architecture, LLNs and other specialised networks
rfc7368 are considered stub areas of the homenet and are thus not expected
rfc7368 to act as a transit for traffic between more traditional media.
So the gateway machine (the 6LBR) will run the HOMENET routing protocol and
the LLN routing protocol (RPL, or some other mesh-under protocol), but the
HOMENET routing protocol will never be run by the sensors.
The section 9, security consideration does indeed miss the mark.
Given that HNCP/DNCP would take care of higher identity and authorization
operations, and would produce some set of anchored credentials for the
routing protocols. the security question is not:
does the protocol support HMAC-FOOBAR.
The questions are rather:
1) how does the cost and convergence of the protocol change if security
considerations force the use of (secured 1:1) unicast for all messages
rather than multicast?
2) does the protocol include an asymetric method for authentication?
We know that multicast is hard to secure using symetric methods as all
parties involved can impersonate any other party. To what extent this is a
concern in homenet is not yet known, but on the other hand, in every
risk/cost/benefit analysis, if the cost of securing things is low enough,
it may make no sense not to...
In section 10, it is useful to know if multicast is supported; it is telling
that nobody has implemented multicast routing in ISIS. It would be
interesting to know how successful multicast routing is in other Link State
and Distance Vector protocols are. (Can Babel just include DVMRP for
instance? Why did nobody implement multicast for ISIS?)
A question which I did not see addressed is about debugging.
How easily can one (perhaps more capable, or having better management
interface) router give diagnostics about problems that might be occuring
elsewhere in the homenet?
Can one deal with broken/mis-having peer routers in a unilateral fashion?
(Consider the ability for parents to mitigate a dispute among technically
astute teenagers, while keeping both online)
Can one get diagnostics from just watching the traffic?
As much as we expect the network to be auto-tuning and auto-configuring and
self-healing; if people do get involved, which one is easier to understand?
{my comments after reading the thread}
Important things that I took out of the discussion:
1) Source address specific routing likely doesn't exist in some hardware.
My response is mostly: we often no idea what hardware can due to NDAs.
The movement (see netdev01.org conference this past week) is towards
having hardware which just lives under the linux kernel and its
configuration is transparent to userspace
2) Layer-2 aspect of ISIS.
We didn't discuss the fact that Babel runs over UDP, while IS-IS runs
directly over layer 2. This has a number of consequences, most notably
related to ease of implementation, portability, and the ability to run
over tunnels (say, GRE or OpenVPN in tun mode).
It also, btw, makes it unable to run over 15.4, since there is no ethernet
type. 6lo also has been defining ways to run IPv6/6lowPAN over other media
that have never seen IPv6. Probably doesn't matter as long as these are
really *LLNs*, but it could be that some of these technologies (802.15.4g has
much bigger packet sizes...) get used in new and unanticipated ways in the
IPv6 is dominant future.
3) metrics.
We don't know how we will assign link metrics, so we don't know how important
X-bit metrics are.
4) convergence over 802.11 MAC...
5) some amount of my processor is slower than yours and still ran protocol XYZ
(http://www.phespirit.info/montypython/four_yorkshiremen.htm)
6) discussion about multicast: do we even need it. With responses from
nobody does it to we have 10^X customers right now.
7) one comment was: we need topology, so babel won't work for us.
8) some conversation about whether or not one can get link state for a wired
connection. I don't see that it matters: there could always be another
$9 layer-2 switch between the two routers. That's the problem with
layer-2 switching, we can't see it.
9) then there was a discussion of multiple (wifi) APs, how to either L2-mesh
them to
accomplish mobility, or to do L3-roaming by having stub versions of
homenet routing protocol and/or RIP.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network
Re: [homenet] Routing protocol comparison document
Margaret Wasserman margaret...@gmail.com wrote: More generally, I think -01 puts undue stress on scaling and convergence speed. Sections 3 and 4 can be summarised as any reasonable routing protocol scales sufficiently well and converges sufficiently fast for the needs of Homenet. The sections in the document started from a list of routing features/properties that were discussed in the WG meeting. There was quite a bit of discussion of scaling. In particular, there was a lot of discussion of how these protocols will scale on Wi-Fi. I wasn't entirely sure, during the meeting, what special requirements there are for a routing protocol to scale well on Wi-Fi vs. other link types, but perhaps someone on the WG mailing list can clarify? Counter-intuitively for a broadcast media, multicast on wifi is very expensive because not all stations can hear each other, and some stations require higher power lower-speed transmissions. So each time the AP transmits a multicast packet, it transmits at the highest power, using the slowest method. Many high-end APs (like we use at IETF), will actually deliver multicast via a series of L2 unicast messages. What this means is that a protocol that depends upon multicast to achieve flooding may perform very poorly over wifi compared to a protocol which forms 1:1 links associations. Now, does this matter in the home: how many homenet capable routers do we expect to create adjacencies over wifi? I will claim that over time, if we get this right, that it will be larger than what we see today in the home (which is 1 to 3 APs), but it's on the order of O(p + r): p=number of people in home, r=number of rooms. So assuming some decent high-power 802.11ac in the Bradford house (http://en.wikipedia.org/wiki/Eight_Is_Enough) to link the per-room router to legacy 802.11b and per-person (phone) router to BTLE/PAN, it means we have about 30 routers on the wifi. How much multicast and how much unicast traffic results? -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Op 20 feb. 2015, om 10:57 heeft Mikael Abrahamsson swm...@swm.pp.se het volgende geschreven: On Fri, 20 Feb 2015, Andrew Mcgregor wrote: Why? PIM and MLD snooping are pretty standard on very low-end enterprise switches, which will be next year's midrange consumer models. If the dumb-as-rocks stuff goes away, that would generally make people happier. There are enterprise switches out there currently (pretty expensive ones) that still do not have MLD snooping, and the ones having PIM snooping is most likely a lot less. I've been in the networking industry for close to 20 years, the first bridge I laid hands on was a pretty advanced thing back in the time with 3 AUI ports, and could barely do 10 megabit/s. I've then seen the evolution into 100meg hubs, then 10/100 dual speed hubs (basically two hubs with a switch in between), to 10/100 switches with all ports switched, to gig equivalent etc. During this entire time, switches that could do IGMP snooping has always been substantially more expensive, mostly (I guess) they couldn't be implemented in pure switch silicon, but always required administration interface, operating system etc. Still today, these typically cost 100 USD or more, when you can buy a stupid one for 30USD. So yes, over time this might change, but I still think there will be cost involved. It might be that the h omenet routers are going to look quite different than the typical router we see today when it comes to phsyical ports. Or perhaps they're only going to have 2-3 ports and the rest is going to be wifi. What do I know. What I do know is that so far, cable has always been a lot better than radio. Lots of support calls to ISPs end up being related to wifi problems. I have CAT6 to every room in my apartment, but then again, I am not a typical user. However, I often speak to people who have performance problems who then end up pulling a physical cable and after that their problems are solved. With 60GHz wifi, you're going to need line-of-sight to every AP from the clients, which will probably be located in the ceiling in every room where you want good performance. These APs are going to need physical cables for uplinks to get any meaningful bump in performance. I have thought of this as mostly L3 network. What I can add: the multicast snooping feature could be somewhat behind development and deployment of the standards and / or buggy. So some administrators switch off the snooping / rate limiting feature. I do. L3 all the way to switch ports make the network more robust. But this requires L3 forwarding in hardware, multicast routing and adjustments in discovery protocols. Can all multicast forwarding be performed in hardware? Do you have CAT6 to WiFi APs in every room? Can you share experience with moving WiFi devices? Teco I thought the service discovery problem between subnets was being solved or had been solved. From the discussion here the past few days it's clear to me now that the mind image of what a future homenet is differs a lot between participants in this working group. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Routing protocol comparison document
On Fri, 20 Feb 2015, Teco Boot wrote: Do you have CAT6 to WiFi APs in every room? Can you share experience with moving WiFi devices? No, my apartment is covered by a single 5GHz AP in the center of the apartment. I mainly use cabled connections for media players and similar devices since they work much better over full duplex gige than over wifi. If I just could go back to my 1ms RTT Internet access link, things would be a lot better because my current DOCSIS3 cable connection is a lot worse (for instance when it comes to RTT and PDV) than my previous connection I had at the previous apartment which was a lot more consistent. I tend to use a CAT6 ethernet adapter in my laptop when I'm at my desk, even though both my AP and laptop has 802.11ac. Wifi is mostly used to handle mobile devices such as tablets and mobile phones. My experience is that even with state of the art equipment, wifi still is not even close in quality of experience compared to cable, apart from very light use where it's still sufficient. My experience with multiple APs (from other places) is that clients don't switch APs easily enough so they're seldom connected to the optimal AP. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Thanks sharing this. What I can add: Our house is a little bit bigger. It was formerly a farmhouse. It has a stone firewall between living room and formerly hay storage place. This firewall is quit good in blocking RF. My production network has 2 dual band APs. I have good indoor coverage. In summertime, I use WiFi in my garden to watch live TV (iPhone, iPad, MacBook, Android gear). It is partly testing, partly following Tour de France, news etc. My partner is less a geek and carries the TV, coax and power cables. Still possible with some analogue channels. Soon we have to carry a lot more stuff to decode DTV, this is bad. Or watch over WiFi. I don't want to CAT6 my garden, sorry. Walking from living room to desk to garden means AP switch-over. I used to have 2.4 and 5GHz SSIDs, this doesn't work well. With exact same SSID and keys, handover works. Not well, but it works. With different SSIDs and different IP subnets: no, total failure. There are WiFi AP kits around that operate in same channel and spoof AP BSSID. Roaming is transparent for clients. Nice idea, not accepted by standards bodies nor by industry. Back to my point: I want L3 on each and every homenet box. At the same time, I want high performance wireless links. It must be cheap, I don't want to pay € 1000 for a WLC and €400 for each AP. As long as homenet enlarges my WiFi problem, it is useless for me. And I thought I was candidate for early adoption, as I have multiple APs, a wired backbone, thinking of dual ISP links etc. And as geek, I want to pay a bit more for high performance and I am able to troubleshoot a bit. Back to the subject: What are the requirements of a high performance WiFi home network to the homenet routing protocol? I guess we don't know. Teco Op 20 feb. 2015, om 13:17 heeft Mikael Abrahamsson swm...@swm.pp.se het volgende geschreven: On Fri, 20 Feb 2015, Teco Boot wrote: Do you have CAT6 to WiFi APs in every room? Can you share experience with moving WiFi devices? No, my apartment is covered by a single 5GHz AP in the center of the apartment. I mainly use cabled connections for media players and similar devices since they work much better over full duplex gige than over wifi. If I just could go back to my 1ms RTT Internet access link, things would be a lot better because my current DOCSIS3 cable connection is a lot worse (for instance when it comes to RTT and PDV) than my previous connection I had at the previous apartment which was a lot more consistent. I tend to use a CAT6 ethernet adapter in my laptop when I'm at my desk, even though both my AP and laptop has 802.11ac. Wifi is mostly used to handle mobile devices such as tablets and mobile phones. My experience is that even with state of the art equipment, wifi still is not even close in quality of experience compared to cable, apart from very light use where it's still sufficient. My experience with multiple APs (from other places) is that clients don't switch APs easily enough so they're seldom connected to the optimal AP. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Teco Boot wrote: Back to the subject: What are the requirements of a high performance WiFi home network to the homenet routing protocol? I guess we don't know. Within the current framework to solve this problem with what exists today when it comes to clients, I would say we need either: 1. HNCP helps set up an overlay L2 tunnel infrastructure connecting all the APs using the same SSID, so the SSID can have the same L2 domain. This would probably mean we want to increase MTU on the physical links to avoid fragmentation. Messy. Possibly we could advertise lower MTU on the wifi network to minimize fragmentation if we don't raise MTU. 2. We set up some kind of L2 switching domain between the APs. This would require VLAN support in the HGWs, and something to set this up with loop avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as control plane, that way we could possibly run the same IGP for both L2 and L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds like an understatement. Frankly, I don't know how to solve this without a lot of complication. We need clients to be able to change IPv6 addresses without losing existing connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two connections at once and inform the application that one address is going away soon so it can do its thing to try to handle this? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
So Teco, to satisfy your use case, which I share, you would actually need the homenet to identify all Wifi access points that are being used to serve hosts, and treat those as a single subnet, correct? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Mikael, Back to the subject: What are the requirements of a high performance WiFi home network to the homenet routing protocol? I guess we don't know. Within the current framework to solve this problem with what exists today when it comes to clients, I would say we need either: 1. HNCP helps set up an overlay L2 tunnel infrastructure connecting all the APs using the same SSID, so the SSID can have the same L2 domain. This would probably mean we want to increase MTU on the physical links to avoid fragmentation. Messy. Possibly we could advertise lower MTU on the wifi network to minimize fragmentation if we don't raise MTU. 2. We set up some kind of L2 switching domain between the APs. This would require VLAN support in the HGWs, and something to set this up with loop avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as control plane, that way we could possibly run the same IGP for both L2 and L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds like an understatement. Frankly, I don't know how to solve this without a lot of complication. why do you think this has to be solved at L2? We need clients to be able to change IPv6 addresses without losing existing connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two connections at once and inform the application that one address is going away soon so it can do its thing to try to handle this? at least you can do: L3 - route injection (got a routing protocol there already, use it) L3.5 - SHIM6. not deployable L4/L5 - MP-TCP L5/L7 - MOSH cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
There are good proposal how to do servicce discovery in homenets or the like with DNS-SD (/mDNS), but i think we should still worry about compatibility with UPnP. Both of these requirements (UPnP and DNS-SD) are IMHO better solved with router-level proxy solutions than with ASM IP multicast. FYI. I did a presentation to DLNA (which has a lot of key UPnP people) that warned them to start thinking about service discovery in the multi-router world, and the world where more and more Wi-Fi APs are limiting the multicast that makes it to Wi-Fi devices. I mentioned the DNS-SD proxy work, homenet, and told them: - People have started to study the current quantity of multicast traffic and its impact on power consumption by battery-operated Wi-Fi devices. http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-00 - Concern is growing and proposals are starting to appear for ways to decrease the quantity of multicast messages. http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00 My recommendations were that they had 2 basic options of either also supporting DNS-SD / mDNS for service discovery, or defining a SSDP proxy similar to what I expect will be done for DNS-SD. Anyway, I told them I'd keep them updated on the state of affairs regarding this issue. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
I have seen more L2 switches that have broken IGMP/MLD snooping than working ones. I am not aware of real proliferation of PIM snooping. Snooping in transit LANs with PIM is a bad idea anyhow, and i have tried to steer any customer who asked me away from it. Bidir-PIM makes snooping particularily difficult. For once you have to track DF-winner election messages (difficult) and secondly you have to then flood all multicast to all DF winners because you don't know which group-range is served by which RP. IMHO, there is never enough multicast to justify this snooping complexity. The only thing to worry about is what packets to send out from a router to ensure the snooping doesn't screw up the traffic flow. I would be surprised to find equipemnt that does PIM snooping by default. So, i'd recommend to a homenet router: - even if you don't do PIM, send out PIM Hellos. This should effectively make all stupid enterprise class IGMP/MLD snooping switches (that often have broken IGMP/MLD snooping) send you all multicast traffic (inhibits snooping). - Still send MLD/IGMP memberships to get traffic through the L2 home equipment that has likely never heard about PIM. I'd guess that eg: powerline equipment falls into this category. Cheers Toerless On Fri, Feb 20, 2015 at 11:04:41AM +1100, Andrew Mcgregor wrote: Why? PIM and MLD snooping are pretty standard on very low-end enterprise switches, which will be next year's midrange consumer models. If the dumb-as-rocks stuff goes away, that would generally make people happier. On 20 February 2015 at 05:22, Mikael Abrahamsson swm...@swm.pp.se wrote: On Thu, 19 Feb 2015, Ted Lemon wrote: On Feb 19, 2015, at 1:08 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: I would like my router-to-router links to not have a lot of hosts in them if I can avoid it. Why is that? If we're going to be routing multicast within the home, we're most likely going to have to use some kind of variant of PIM. Asking the L2 switches people connect to the router to support both PIM and MLD snooping seem like it might be asking too much. I might be wrong though. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Andrew McGregor | SRE | andrewm...@google.com | +61 4 1071 2221 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- --- Toerless Eckert, eck...@cisco.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, Feb 20, 2015 at 02:57:21PM +0100, Mikael Abrahamsson wrote: L3 - route injection (got a routing protocol there already, use it) This sounds like it needs at least a coordination protocol between the APs? NO, just between the first-hop (homenet) routers. Should work with unchanged of the shelf crap-APs as long as they're attached to a homenet router. Cheers Toerless ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Were you before me? http://www.ietf.org/mail-archive/web/homenet/current/msg00971.html (November 2011) More than three years later, same discussion. That makes me sad. Teco Op 20 feb. 2015, om 15:14 heeft Ted Lemon mel...@fugue.com het volgende geschreven: On Feb 20, 2015, at 8:22 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: 2. We set up some kind of L2 switching domain between the APs. This would require VLAN support in the HGWs, and something to set this up with loop avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as control plane, that way we could possibly run the same IGP for both L2 and L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds like an understatement. Long ago I proposed using Trill to make this work, but nobody listened... :) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On 02/18/2015 11:54 PM, Mikael Abrahamsson wrote: On Wed, 18 Feb 2015, Michael Thomas wrote: But we're not talking about an interpreted language in the forwarding plane, right? Is the load from routing protocols we're talking about likely to have any noticeable effect on the the forwarding rate? even when you're running hot on the routing daemon side, you're not too likely to be running hot on the forwarding side because something is hosed, right? The complaints about the Erlang implementation has so far been on memory and flash footprint, not CPU resources and affecting performance. The above is true for most interpreted languages, such as python etc. When you install the environment, they're going to use noticable memory and disk space. Next application that needs the environment won't add much to the footprint though, it's the environment itself that takes space. My Python executable on my debian box is 2.7 megabyte. I don't know about the rest. So if one wants to run Python on the home gateway, that would also use significant space. But forwarding will be done the same way regardless of what routing protocol we use, that'll be done by the kernel. The routing protocol just programs the RIB/FIB. One nice side-effect of putting in, say, a headless android into a router is that it would forevermore insure that there's plentiful memory, just like it did for cell phones. It's not like we physically can't get enough ram/flash into those boxen after all... it's the will to bear the cost that's really at issue. A better development environment for home routers would *really* help development efforts along. From what I've seen they suck out loud. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
I don't know. Homenet multicast is an open issue. But I don't think this use case represents a serious problem, because as far as I can tell streaming video is not done using multicast in practice anyway. Sorry, bad assumption. I just finished working on a TV streaming project for an ISP and there is lots of multicast there. All live TV channel streams to STBs are multicast and this is a common setup amongst ISPs. OTT video does not use multicast. IPTV deployments do use multicast. Those that I'm aware of require use of the provider-supplied CE router, which has an IGMP proxy (and MLD proxy if IPv6 multicast is supported) for LAN-to-WAN multicast management. Where Wi-Fi distribution of these multicast streams is supported, it is only done on a dedicated (and highly managed and somewhat proprietary) Wi-Fi network, that is distinct from the general-purpose (and not professionally managed) Wi-Fi network. The LAN interfaces of the provider-supplied CE router do tend to have IGMP/MLD snooping, to keep from flooding the general-purpose network interfaces with large multicast streams. There may also be a coax networking interface. If there is, this also tends to be dedicated and highly managed. Where Ethernet is used for distribution of multicast, it is done so that the provider STBs are all attached to the provider CE router via the same Ethernet port (and no other devices use that port) and there are no intervening routers. I mentioned at the last IETF that I expect some home networks to have managed and unmanaged segments. I don't consider the dedicated, managed segments to be part of the homenet domain. I would hope that the provider-supplied CE router would support homenet on its general purpose network interfaces. I'd be curious to learn about multicast IPTV deployments that allow users to supply their own CE routers and send multicast streams on network segments that are also used for general-purpose home networking (especially general-purpose Wi-Fi networks). BTW, the dedicated, highly-managed and somewhat proprietary Wi-Fi delivery of IPTV multicast streams has been very successful. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Has the group considered a Bier model for multicast in the home? On 2/20/15, 9:41 AM, Toerless Eckert eck...@cisco.com wrote: I have seen more L2 switches that have broken IGMP/MLD snooping than working ones. I am not aware of real proliferation of PIM snooping. Snooping in transit LANs with PIM is a bad idea anyhow, and i have tried to steer any customer who asked me away from it. Bidir-PIM makes snooping particularily difficult. For once you have to track DF-winner election messages (difficult) and secondly you have to then flood all multicast to all DF winners because you don't know which group-range is served by which RP. IMHO, there is never enough multicast to justify this snooping complexity. The only thing to worry about is what packets to send out from a router to ensure the snooping doesn't screw up the traffic flow. I would be surprised to find equipemnt that does PIM snooping by default. So, i'd recommend to a homenet router: - even if you don't do PIM, send out PIM Hellos. This should effectively make all stupid enterprise class IGMP/MLD snooping switches (that often have broken IGMP/MLD snooping) send you all multicast traffic (inhibits snooping). - Still send MLD/IGMP memberships to get traffic through the L2 home equipment that has likely never heard about PIM. I'd guess that eg: powerline equipment falls into this category. Cheers Toerless On Fri, Feb 20, 2015 at 11:04:41AM +1100, Andrew Mcgregor wrote: Why? PIM and MLD snooping are pretty standard on very low-end enterprise switches, which will be next year's midrange consumer models. If the dumb-as-rocks stuff goes away, that would generally make people happier. On 20 February 2015 at 05:22, Mikael Abrahamsson swm...@swm.pp.se wrote: On Thu, 19 Feb 2015, Ted Lemon wrote: On Feb 19, 2015, at 1:08 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: I would like my router-to-router links to not have a lot of hosts in them if I can avoid it. Why is that? If we're going to be routing multicast within the home, we're most likely going to have to use some kind of variant of PIM. Asking the L2 switches people connect to the router to support both PIM and MLD snooping seem like it might be asking too much. I might be wrong though. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Andrew McGregor | SRE | andrewm...@google.com | +61 4 1071 2221 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- --- Toerless Eckert, eck...@cisco.com ___ 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] Routing protocol comparison document
L3 - route injection (got a routing protocol there already, use it) Yes, just put a stub router on the host and advertise /128. As far as I'm aware, current HNCP doesn't provide a way for a host to request a subnet-independent /128. What's the thinking on that? Just grab a /128 from whichever subnet you happen to be connected to at boot, and advertise that? L3.5 - SHIM6. not deployable L4/L5 - MP-TCP L5/L7 - MOSH I don't think that's specific to Homenet -- being able to deal with multiple addresses that change over time is something that our stacks don't deal with very well. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
I am not mandating that each and every device is in its own broadcast domain, I am however advocating that we leave the model that has been prevalent for 10-15 years at least, ie that a home gateway has a WAN port and 4 LAN ports, and these 4 ports are bridged. You certainly have a point -- that's something we never discussed, and it appears that there's no consensus. I'm saying the typical device should have 4-5 L3 ports. You're then free to connect one of these to your L2 switch if you so please. I'll just point out that on all the hardware I know this is configurable -- it's quite possible to set up an OpenWRT router to put each Ethernet port on a different VLAN. So perhaps a Homenet router could ship with the LAN ports bridged, and have a configuratifon option somewhere in the Beware the tiger tab of the Advanced menu that allows unbridging selected ports? (I'm sure somebody will point out that the right configuration could be chosen automatically, but I'm not sure I'm comfortable with the set of interfaces changing at runtime on a home router.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Hi Barbara, OTT video does not use multicast. IPTV deployments do use multicast. Those that I'm aware of require use of the provider-supplied CE router, which has an IGMP proxy (and MLD proxy if IPv6 multicast is supported) for LAN-to-WAN multicast management. Where Wi-Fi distribution of these multicast streams is supported, it is only done on a dedicated (and highly managed and somewhat proprietary) Wi-Fi network, that is distinct from the general-purpose (and not professionally managed) Wi-Fi network. The LAN interfaces of the provider-supplied CE router do tend to have IGMP/MLD snooping, to keep from flooding the general-purpose network interfaces with large multicast streams. There may also be a coax networking interface. If there is, this also tends to be dedicated and highly managed. Where Ethernet is used for distribution of multicast, it is done so that the provider STBs are all attached to the provider CE router via the same Ethernet port (and no other devices use that port) and the re are no intervening routers. I mentioned at the last IETF that I expect some home networks to have managed and unmanaged segments. I don't consider the dedicated, managed segments to be part of the homenet domain. I would hope that the provider-supplied CE router would support homenet on its general purpose network interfaces. I'd be curious to learn about multicast IPTV deployments that allow users to supply their own CE routers and send multicast streams on network segments that are also used for general-purpose home networking (especially general-purpose Wi-Fi networks). The above is correct. Provider-supplied CPEs are currently necessary and intermediate routers are not supported. The TV streams can be on a separate VLAN. But this is what is currently done because of the difficulty of doing it over the regular home network. It doesn't mean we should design Homenet in the same way. I'd rather see that providers supply Homenet routers to their customers and that the multicast TV streams just work. Cheers, Sander ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Lets hope UPnP/DLNA are starting to consider to cooperate with IETF on service discovery. Cooperate is such a strong word. :) They are aware of the issue, they will be kept informed as to how the issue is progressing and what homenet and dnsext are doing to tackle the issue, and they know what their options are. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 20, 2015, at 11:33 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Has the group considered a Bier model for multicast in the home? As in a place where you put dead people? Bier is a new working group in the routing area. https://datatracker.ietf.org/wg/bier/charter/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Thanks, Barbara. Lets hope UPnP/DLNA are starting to consider to cooperate with IETF on service discovery. On Fri, Feb 20, 2015 at 02:37:38PM +, STARK, BARBARA H wrote: There are good proposal how to do servicce discovery in homenets or the like with DNS-SD (/mDNS), but i think we should still worry about compatibility with UPnP. Both of these requirements (UPnP and DNS-SD) are IMHO better solved with router-level proxy solutions than with ASM IP multicast. FYI. I did a presentation to DLNA (which has a lot of key UPnP people) that warned them to start thinking about service discovery in the multi-router world, and the world where more and more Wi-Fi APs are limiting the multicast that makes it to Wi-Fi devices. I mentioned the DNS-SD proxy work, homenet, and told them: - People have started to study the current quantity of multicast traffic and its impact on power consumption by battery-operated Wi-Fi devices. http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-00 - Concern is growing and proposals are starting to appear for ways to decrease the quantity of multicast messages. http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00 My recommendations were that they had 2 basic options of either also supporting DNS-SD / mDNS for service discovery, or defining a SSDP proxy similar to what I expect will be done for DNS-SD. Anyway, I told them I'd keep them updated on the state of affairs regarding this issue. Barbara -- --- Toerless Eckert, eck...@cisco.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Toerless Eckert wrote: So foremost, it would be good to understand if there really is home L2 equipment that MUST see MLD to operate correctly. Otherwise i'd happily ignore the problem and say there is enough bandwidth to just NOT DO snooping but have multicast be flooded in the L2 segments. I know of ATA (VoIP) devices with 10/half uplinks that fall over HARD when they receive two simultaneous IPTV streams when doing channel switching. So it's not only about bandwidth, but about how much traffic these kinds of devices are designed to receive. Also, remember that we're going to 4k IPTV streams that might be in the 20 megabit/s range, and we might be doing multiples of them. All devices on the subnet will receive this if there is no MLD/PIM snooping precent. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Markus Stenberg wrote: - have clients talk stub RP + stub HNCP, be done with it Oooh, if we want to require changes to clients, I have all kinds of ideas how to solve this in other ways than you propose. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
It seems pretty clear that over time, the bulk of video will be unicast, in order to meet on-demand needs. There will always be a few items that folks really want to watch live, and thus where multicast may add value. But making multicast the design driver for home networking archtiecture seems backwards to me. Yours, Joel On 2/20/15 1:22 PM, Dave Taht wrote: On Fri, Feb 20, 2015 at 10:10 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Fri, 20 Feb 2015, Toerless Eckert wrote: So foremost, it would be good to understand if there really is home L2 equipment that MUST see MLD to operate correctly. Otherwise i'd happily ignore the problem and say there is enough bandwidth to just NOT DO snooping but have multicast be flooded in the L2 segments. I know of ATA (VoIP) devices with 10/half uplinks that fall over HARD when they receive two simultaneous IPTV streams when doing channel switching. So it's not only about bandwidth, but about how much traffic these kinds of devices are designed to receive. Also, remember that we're going to 4k IPTV streams that might be in the 20 megabit/s range, and we might be doing multiples of them. All devices on the subnet will receive this if there is no MLD/PIM snooping precent. Is there a formal definition of IPTV? as used here, it seems to imply multicast. Frankly, until now, I was expecting the world to go to a HAS model for content, especially big content. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Routing protocol comparison document
On Fri, Feb 20, 2015 at 10:10 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Fri, 20 Feb 2015, Toerless Eckert wrote: So foremost, it would be good to understand if there really is home L2 equipment that MUST see MLD to operate correctly. Otherwise i'd happily ignore the problem and say there is enough bandwidth to just NOT DO snooping but have multicast be flooded in the L2 segments. I know of ATA (VoIP) devices with 10/half uplinks that fall over HARD when they receive two simultaneous IPTV streams when doing channel switching. So it's not only about bandwidth, but about how much traffic these kinds of devices are designed to receive. Also, remember that we're going to 4k IPTV streams that might be in the 20 megabit/s range, and we might be doing multiples of them. All devices on the subnet will receive this if there is no MLD/PIM snooping precent. Is there a formal definition of IPTV? as used here, it seems to imply multicast. Frankly, until now, I was expecting the world to go to a HAS model for content, especially big content. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Am 19. Februar 2015 20:05:56 MEZ, schrieb Ted Lemon mel...@fugue.com: Hm, I will have to try it out. Is it in a distribution? ohybridproxy in openwrt. It's mainly useful with hnetd (hncp) though. Manual configuration without hncp is a bit awkward since you need to name each link manually and on every router configure the resolver (e.g. dnsmasq). I guess we might want to provide a little example for 2 links at some point. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Agree. I would not architect around multi-hop multicast, subnet OK, targeted probably. Not sure everyone has had the pleasure of running large IP multicast infrastructures running video, it is a wonderful challenge. It also has the side benefit of encouraging poorly designed applications. Interoperability on even core routers for IP multicast barely exists. In a home environment, although smaller, will be even less wonderful. Just the race conditions between PIM and the IGP are always challenging. On 2/20/15, 1:50 PM, Joel M. Halpern j...@joelhalpern.com wrote: It seems pretty clear that over time, the bulk of video will be unicast, in order to meet on-demand needs. There will always be a few items that folks really want to watch live, and thus where multicast may add value. But making multicast the design driver for home networking archtiecture seems backwards to me. Yours, Joel On 2/20/15 1:22 PM, Dave Taht wrote: On Fri, Feb 20, 2015 at 10:10 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Fri, 20 Feb 2015, Toerless Eckert wrote: So foremost, it would be good to understand if there really is home L2 equipment that MUST see MLD to operate correctly. Otherwise i'd happily ignore the problem and say there is enough bandwidth to just NOT DO snooping but have multicast be flooded in the L2 segments. I know of ATA (VoIP) devices with 10/half uplinks that fall over HARD when they receive two simultaneous IPTV streams when doing channel switching. So it's not only about bandwidth, but about how much traffic these kinds of devices are designed to receive. Also, remember that we're going to 4k IPTV streams that might be in the 20 megabit/s range, and we might be doing multiples of them. All devices on the subnet will receive this if there is no MLD/PIM snooping precent. Is there a formal definition of IPTV? as used here, it seems to imply multicast. Frankly, until now, I was expecting the world to go to a HAS model for content, especially big content. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Routing protocol comparison document
On Fri, Feb 20, 2015 at 11:34 AM, Steven Barth cy...@openwrt.org wrote: Am 19. Februar 2015 20:05:56 MEZ, schrieb Ted Lemon mel...@fugue.com: Hm, I will have to try it out. Is it in a distribution? ohybridproxy in openwrt. It's mainly useful with hnetd (hncp) though. Manual configuration without hncp is a bit awkward since you need to name each link manually and on every router configure the resolver (e.g. dnsmasq). I guess we might want to provide a little example for 2 links at some point. I would like to deploy hncp in my upcoming make-wifi-fast testbed. However the biggest headache is ensuring that all the routers inbetween have hncp burned into them, and are only acting as relays as I generally only obtain a few (/60) real IPv6 prefixes per GW and they only need to be on the APs. GW1 - routerA - routerB - routerC - routerD - AP1 | GW2 - routerE - routerF - routerG - routerH - AP2 | AP3 GW3 ... (the actual topology of the testbed is way more complex than this (covering ethernet, wifi, and moca) and I am not going into it here) 1) is there a way to configure hncpd as purely a relay, and NOT do any address assignment at all on routers B,C,D,F,G,H? 2) have you tested that it is indeed possible to get the separate ipv6 prefixes from GW1,GW2,GW3 to AP1,AP2, AP3? 3) Can ULA and Real address assignment be distinguished along the way? I have no problem assigning ULAs to the routers, but dont want to use up real addresses on them. 4) What happens when someone pulls the plug on GW1, it reboots, and gets a new Ipv6 subnet (I have seen comcast do this to me every time that happens with the code I have in place now - no retraction, and I go through hell manually eliminating every former prefix from the network. Yes. I have upses. And cerowrt, at least, stays up for 90+ days without a problem. But it happens and sucks when it does) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Hi, On Thu, Feb 19, 2015 at 08:43:26AM +0100, Mikael Abrahamsson wrote: We're talking about a protocol decision here. People seem to focus a lot on the running code part here. ISIS is used for numerous things of apart frmo the MPLS and Traffic engineering space, we also have IEEE 802.1aq (SPB) and TRILL, it's also used in the GMPLS control plane. There are probably 10-20+ commercial implementations of ISIS, if not perhaps the exact TLVs we're talking about here. Most of not all of these standards are described in standards track RFCs. Against this, we have Babel, which as far as I can tell has a single implementation that has been forked into two, and is based on a few experimental RFCs. Just to voice something from the opposite side of the spectrum - I'm a fan of do one thing and do it well approaches, and not so much of a oh, we have a kitchen sink here, let's see if we can turn it into a living room table. So for me, the fact that ISIS is used for umpteen other things outside the homenet environment isn't exactly a plus side. Yes, it is understood that basic ISIS works (exchanging TLVs, establishing topology) - but if you look at it from an implementors point of view that does not have many years of ISIS background, just figuring out which parts of the heap of potential ISIS use cases they need to implement sounds much more time-consuming than just taking the Babels implementation and compiling it for the platform of choice... We're not talking about a routing protocol for every possible use case here - we're talking about a fairly well defined environment (aka fairly small number of devices, IPv4 and IPv6 only, and implementations constrained by lack of clue on the manufacturer side). 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Thu, Feb 19, 2015 at 12:52 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Thu, 19 Feb 2015, Gert Doering wrote: We're not talking about a routing protocol for every possible use case here - we're talking about a fairly well defined environment (aka fairly small number of devices, IPv4 and IPv6 only, and implementations constrained by lack of clue on the manufacturer side). Well, to further explain my concern regarding that and current approach, I now see that current proposals is to have the HNCP and $ROUTINGPROTOCOL split. If we choose Babel, then we've locked outselves into this split and HNCP needs to be extended to handle every future functionality needed since babel can't do much more than it already does. For instance the security work now being done on HNCP. Does ISIS already offer the same functionality? I can't evaluate security very well, I don't know how many active in this working group that can. I would rather use an already standardized mechanism for doing this. It's been a while since the decision to create HNCP (which was originally designed so it could work inside a TLV carrying routing protocol) instead of carrying the required homenet information in the routing protocol. The basis for this decision, is that still true (that the routing protocol WGs and implementors refused to accept the TLV types needed and the APIs needed)? It's been what, 1.5-2 years since then? We've already noted that HNCP looks awfully close to a link state protocol and duplicates quite a lot of of functionality. There is talk about how complicated ISIS is. How complicated is DNCP/HNCP going to be when we're done with it? How many LoC is it now? hnetd exclusive of the library dependencies (which I could easily run a sloccount for, also, if you care) d@nuc-client:~/git/hnetd$ sloccount --personcost 11 generic src test openwrt SLOCDirectorySLOC-by-Language (Sorted) 12936 src ansic=12936 5806testansic=5806 417 generic sh=417 99 openwrt sh=99 Totals grouped by language (dominant language first): ansic:18742 (97.32%) sh: 516 (2.68%) Total Physical Source Lines of Code (SLOC)= 19,258 Development Effort Estimate, Person-Years (Person-Months) = 4.47 (53.59) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 0.95 (11.35) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 4.72 Total Estimated Cost to Develop = $ 1,178,896 (average salary = $110,000/year, overhead = 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL. SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to redistribute it under certain conditions as specified by the GNU GPL license; see the documentation for details. Please credit this data as generated using David A. Wheeler's 'SLOCCount'. Babel on the other hand: SLOCDirectorySLOC-by-Language (Sorted) 10737 babeld ansic=10474,sh=263 Totals grouped by language (dominant language first): ansic:10474 (97.55%) sh: 263 (2.45%) Total Physical Source Lines of Code (SLOC)= 10,737 Development Effort Estimate, Person-Years (Person-Months) = 2.42 (29.02) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 0.75 (8.99) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 3.23 Total Estimated Cost to Develop = $ 638,353 (average salary = $110,000/year, overhead = 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL. SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to redistribute it under certain conditions as specified by the GNU GPL license; see the documentation for details. Please credit this data as generated using David A. Wheeler's 'SLOCCount'. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On 19.02.2015 10:00, Dave Taht wrote: hnetd exclusive of the library dependencies (which I could easily run a sloccount for, also, if you care) d@nuc-client:~/git/hnetd$ sloccount --personcost 11 generic src test openwrt SLOCDirectorySLOC-by-Language (Sorted) 12936 src ansic=12936 5806testansic=5806 417 generic sh=417 99 openwrt sh=99 As a rough estimate of those 12-13 KLOC only about one sixth should be related to DNCP. So I very much doubt that hooking it up to a 3rd-party daemon for topology/TLV-management would make any noticable impact. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On 19.2.2015, at 10.52, Mikael Abrahamsson swm...@swm.pp.se wrote: We're not talking about a routing protocol for every possible use case here - we're talking about a fairly well defined environment (aka fairly small number of devices, IPv4 and IPv6 only, and implementations constrained by lack of clue on the manufacturer side). Well, to further explain my concern regarding that and current approach, I now see that current proposals is to have the HNCP and $ROUTINGPROTOCOL split. If we choose Babel, then we've locked outselves into this split and HNCP needs to be extended to handle every future functionality needed since babel can't do much more than it already does. For instance the security work now being done on HNCP. Does ISIS already offer the same functionality? I can't evaluate security very well, I don't know how many active in this working group that can. I would rather use an already standardized mechanism for doing this. Luckily I can. The comparison document unfortunately lacks references, and I am not motivated enough to look it up, but based on the comparison document, it does not. IS-IS essentially offers just the good old ‘password’ scheme (and so does Babel). It is not user-friendly, that’s why DNCP has 2 other PKI based modes too (CA hierarchy, trust consensus). Certainly, we could argue that we use something like mini-HNCP to ‘bootstrap’ IS-IS, but I am not sure that is a clever idea either. It's been a while since the decision to create HNCP (which was originally designed so it could work inside a TLV carrying routing protocol) instead of carrying the required homenet information in the routing protocol. The basis for this decision, is that still true (that the routing protocol WGs and implementors refused to accept the TLV types needed and the APIs needed)? At the time there were fears of routing protocol peeing in it’s pants, given sufficiently churny data, and/or political process stalling us for years. I think we have seen the later effect already. I do not believe in the former. It's been what, 1.5-2 years since then? We've already noted that HNCP looks awfully close to a link state protocol and duplicates quite a lot of of functionality. Right. It is essentially bit more modern take on a link state routing protocol. So if you bring it up, I bring up the another argument - why not route using it? Cost of doing _that_ is ~100 LoC (+ whatever fancy thing we want to do with metrics). Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Hi, On Thu, Feb 19, 2015 at 11:15:38AM +0200, Markus Stenberg wrote: [ HNCP ] Right. It is essentially bit more modern take on a link state routing protocol. So if you bring it up, I bring up the another argument - why not route using it? Cost of doing _that_ is ~100 LoC (+ whatever fancy thing we want to do with metrics). This is actually something I have been wondering about. Why not use HNCP to do all the work, when it's already nicely establishing a communication infrastructure? This decision happened before I joined this list... 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 pgpjOid7fxZkH.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Thu, Feb 19, 2015 at 11:18 AM, Ted Lemon mel...@fugue.com wrote: On Feb 19, 2015, at 2:11 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: I'd imagine it's easier to do AQM on routed ports instead of switched ports as well, that's where I can imagine CeroWRT choosing this approach. I don't think it is easier to do AQM on routed ports. If you do the easy version of AQM for switched ports, that's easy; if you do per-port AQM I think it's equally hard in both cases. In either case AQM and FQ has to be per port in the switch hardware itself. I have been patiently awaiting for that sort of hardware to arrive. On most consumer routers the cpu forwarding path isnt capable of gbit rates in the first place. If you are doing software bridging (say between wired and wireless), you apply fq_codel to the underlying interfaces, not the bridge, and you are golden, except for dealing with multicast... The plumbing for the L2 solution would look different than for the L3 solution, and that might make it trickier, though. CeroWRT did this, as far as I understand it, because Dave wanted to shake out cross-subnet issues, not because he felt it was technically preferable in the long run, but perhaps I am misrepresenting his position on the topic. You are correct, I primarily chose routing between tons of interfaces precisely to expose what cross-subnet issues existed in the real world, and to make it be s painful as to inspire those writing code that overused multicast to find unicast solutions! The core things that break are things we long ago identified - mdns and local service discovery, notably. (I have generally found that every android app lets me plug in an ip address for a given service, so for me it hasnt been a huge problem - except that not having a dynamic ipv6 to name mapping makes dynamic ipv6 unusable in such cases) The net result is a lot of cero people said to hell with that and went back to bridging everything, instead of working harder on mdns-proxy, cidr, etc. This microcosm of induced routing pain was also intended to show how multicast didnt scale at all into larger wifi networks in the the small business, or educational campus, that are bridged to wifi, here the problems induced by multicast are so crippling as to leading to the vast establishment of things like AP isolation, which disconnects everyone from everyone else, on the same AP, which to me, is a terrible solution. I do note that not bridging ethernet and wifi together in cero has led to making wifi quite a bit more pleasant and less jittery on apps like webrtc, at least for me, and there is work in play on improving wifi´s aggregation handling and multicast queue management coming up soon. It's good that we're having this discussions since I seem to not be the only one thinking that there should be one port per subnet. I do like occasionally having more than one vlan, but in the general case, routing is far more expensive than switching. The no-nat case here shows the impact of a current 44 entry routing table on downloads, in the present linux 3.18 fib lookup system. http://snapon.lab.bufferbloat.net/~d/openwrt-3.18.7/openwrt-wndr3800-3.18.7.svg and also shows the performance difference between ipv6 and ipv4 on this hardware. There has been some GREAT work on improving linux´s fib lookup system of late, but hardware bridging will always outperform software bridging which will always outperform routing, IMHO. Anyway I cant imagine a homeowner wanting more than 2-3 vlans at most, and most, just one. There is no problem scaling an ethernet broadcast domain to 4096 devices. Using up 16 ports on 16 different /64 subnets is kind of crazy, especially since at least one provider (comcast) is only supplying a /60 in the first place. wifi on the other hand, barely scales to 30 active stations. Indeed, there are two of you! ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Thu, Feb 19, 2015 at 12:14 PM, Dave Taht dave.t...@gmail.com wrote: On Thu, Feb 19, 2015 at 11:18 AM, Ted Lemon mel...@fugue.com wrote: On Feb 19, 2015, at 2:11 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: I'd imagine it's easier to do AQM on routed ports instead of switched ports as well, that's where I can imagine CeroWRT choosing this approach. I don't think it is easier to do AQM on routed ports. If you do the easy version of AQM for switched ports, that's easy; if you do per-port AQM I think it's equally hard in both cases. In either case AQM and FQ has to be per port in the switch hardware itself. I have been patiently awaiting for that sort of hardware to arrive. On most consumer routers the cpu forwarding path isnt capable of gbit rates in the first place. If you are doing software bridging (say between wired and wireless), you apply fq_codel to the underlying interfaces, not the bridge, and you are golden, except for dealing with multicast... The plumbing for the L2 solution would look different than for the L3 solution, and that might make it trickier, though. CeroWRT did this, as far as I understand it, because Dave wanted to shake out cross-subnet issues, not because he felt it was technically preferable in the long run, but perhaps I am misrepresenting his position on the topic. You are correct, I primarily chose routing between tons of interfaces precisely to expose what cross-subnet issues existed in the real world, and to make it be s painful as to inspire those writing code that overused multicast to find unicast solutions! The core things that break are things we long ago identified - mdns and local service discovery, notably. Also firewalling became a log(nports) problem without the special solutions in cerowrt. That became AMAZINGLY slow when we got past 4 interfaces. It still is quite slow even with the pattern match we use there. (I have generally found that every android app lets me plug in an ip address for a given service, so for me it hasnt been a huge problem - except that not having a dynamic ipv6 to name mapping makes dynamic ipv6 unusable in such cases) The net result is a lot of cero people said to hell with that and went back to bridging everything, instead of working harder on mdns-proxy, cidr, etc. This microcosm of induced routing pain was also intended to show how multicast didnt scale at all into larger wifi networks in the the small business, or educational campus, that are bridged to wifi, here the problems induced by multicast are so crippling as to leading to the vast establishment of things like AP isolation, which disconnects everyone from everyone else, on the same AP, which to me, is a terrible solution. I do note that not bridging ethernet and wifi together in cero has led to making wifi quite a bit more pleasant and less jittery on apps like webrtc, at least for me, and there is work in play on improving wifi´s aggregation handling and multicast queue management coming up soon. It's good that we're having this discussions since I seem to not be the only one thinking that there should be one port per subnet. I do like occasionally having more than one vlan, but in the general case, routing is far more expensive than switching. The no-nat case here shows the impact of a current 44 entry routing table on downloads, in the present linux 3.18 fib lookup system. http://snapon.lab.bufferbloat.net/~d/openwrt-3.18.7/openwrt-wndr3800-3.18.7.svg and also shows the performance difference between ipv6 and ipv4 on this hardware. There has been some GREAT work on improving linux´s fib lookup system of late, but hardware bridging will always outperform software bridging which will always outperform routing, IMHO. Anyway I cant imagine a homeowner wanting more than 2-3 vlans at most, and most, just one. There is no problem scaling an ethernet broadcast domain to 4096 devices. Using up 16 ports on 16 different /64 subnets is kind of crazy, especially since at least one provider (comcast) is only supplying a /60 in the first place. wifi on the other hand, barely scales to 30 active stations. Indeed, there are two of you! ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
If people want to choose babel because it works well facing adverse radio conditions in a mesh-networking environment (that I know nothing about), I think this is misrepresenting the argument somewhat. We want a routing protocol that works well in an unadministered network that consists of a mixture of wired and wireless links. In a previous mail, I presented a topology that I think is realistic in a Homenet deployment: Internet --- A --- BC --- is Ethernet .. ... is WiFi Current implementations of Babel are known to work well in such topologies. As far as I am aware, current implementations of IS-IS are not. Getting IS-IS to work well on such topologies is not completely trivial. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
I would note that RFC 7368 says that simple Layer 3 topologies involving as few subnets as possible are preferred in home networks. I presume this is reflective of WG agreement. While it does go on to note that multiple subnets are sometimes needed, mandating that each physical port on the access router be a distinct subnet (much less extending such a mandate further in the home) seems to violate this agreement. Yours, Joel M. Halpern On 2/19/15 1:11 PM, Ted Lemon wrote: On Feb 19, 2015, at 12:33 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: Sure, ISIS could be made smarter when it comes to this, but it all comes down to what the requirements are. Right now when we started to evaluate routing protocols, people started pitching USP for their perticular favorite, and we found out we weren't even on the same page when it comes to requirements, and even what a homenet looks like. I think it is you who are not on the same page, not the working group. The working group recently published a document describing our goals, RFC 7368. Many of the points you have raised as supposed points of disagreement are addressed in the document, although I will admit that it is not always obvious that they have been addressed. The case of routing over Wifi was discussed at length; the text referring to it in the document is here: Due to the use of a variety of diverse underlying link technologies, path selection in a homenet may benefit from being more refined than minimising hop count. Regarding your criticism about people pitching their favorite routing protocols, you seem to be doing precisely that, so the criticism seems a bit unfair. The responses you have been hearing seem like legitimate attempts to address points you have raised on a technical level, not mere advocacy, and it is unfortunate that you would suggest otherwise: I haven't actually seen you raise any technical points in favor of IS-IS, which you seem to be advocating. ___ 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] Routing protocol comparison document
On Thu, 19 Feb 2015, Mikael Abrahamsson wrote: On Thu, 19 Feb 2015, Ted Lemon wrote: On Feb 19, 2015, at 1:55 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: My employer has millions of subscribers using IPv4 multicast TV channels currently. How's that getting through the NAT? IGMP proxy in the HGW. Perhaps should add that we're doing the same thing for IPv6, but using MLD proxy instead, of course. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 19, 2015, at 2:11 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: I'd imagine it's easier to do AQM on routed ports instead of switched ports as well, that's where I can imagine CeroWRT choosing this approach. I don't think it is easier to do AQM on routed ports. If you do the easy version of AQM for switched ports, that's easy; if you do per-port AQM I think it's equally hard in both cases. The plumbing for the L2 solution would look different than for the L3 solution, and that might make it trickier, though. CeroWRT did this, as far as I understand it, because Dave wanted to shake out cross-subnet issues, not because he felt it was technically preferable in the long run, but perhaps I am misrepresenting his position on the topic. It's good that we're having this discussions since I seem to not be the only one thinking that there should be one port per subnet. Indeed, there are two of you! ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 19, 2015, at 2:09 PM 2/19/15, Mikael Abrahamsson swm...@swm.pp.se wrote: On Thu, 19 Feb 2015, Ralph Droms wrote: But I think one of the important points for homenet is that many people will just buy internet devices, not routers and switches. I've been out of the loop so I should go back and check the architecture before I say too much more ... what is the expectation for grouping ports on homenet devices and is there an expectation that people will buy homenet devices and switches and know where to use them both? As far as I know, this hasn't been discussed that much. From a quick look in the arch document, there are all kinds of examples. Looking for instance at 3.2.2.1 we have all kinds of topologies, from router-router links without any hosts on it, to subnets with 2 hosts on them, to shared networks used to inerconnect routers. From what I remember and what I can see the document stating, the solution is supposed to handle all kinds of topologies. I promise to go back and re-read the architecture document because I'm having trouble matching the architecture we're discussing here with the desired properties and logical architectures we want the homenet devices to self-organize into. ..and, of course, if we solve WiFi-wired for DNS-SD, the solution will likely work for some small number of subnets. What is small here? If it works for 2, why wouldn't it work for 50? In theory, sure. In practice, 25x (or maybe 25^2?) things to break. - Ralph -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
I would note that RFC 7368 says that simple Layer 3 topologies involving as few subnets as possible are preferred in home networks. I presume this is reflective of WG agreement. While it does go on to note that multiple subnets are sometimes needed, mandating that each physical port on the access router be a distinct subnet (much less extending such a mandate further in the home) seems to violate this agreement. Yours, Joel M. Halpern +1 Why would we even want to separate these 4 switched ports in the first place ? I know we are L3 people but, this is IMHO, going too far. Don’t kill Ethernet switching. - It works well when you don’t have drastically different throughputs. - It has non-expensive and efficient hardware home-router vendors are used to put into their devices. - Home routers mostly don’t have L3 hardware. They are not able to route at 1Gbps. The goal of introducing L3 routing was to isolate very different link types such as Wifi Vs GigabitEthernet. I know we *did* separate ports in all the homenet demos at bits-n-bites. Maybe this was sending the wrong message. The purpose was to show the principle of introducing routing in the home. I guess next time it will be 2x2 ports instead of 4x1 ports. - Pierre On 2/19/15 1:11 PM, Ted Lemon wrote: On Feb 19, 2015, at 12:33 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: Sure, ISIS could be made smarter when it comes to this, but it all comes down to what the requirements are. Right now when we started to evaluate routing protocols, people started pitching USP for their perticular favorite, and we found out we weren't even on the same page when it comes to requirements, and even what a homenet looks like. I think it is you who are not on the same page, not the working group. The working group recently published a document describing our goals, RFC 7368. Many of the points you have raised as supposed points of disagreement are addressed in the document, although I will admit that it is not always obvious that they have been addressed. The case of routing over Wifi was discussed at length; the text referring to it in the document is here: Due to the use of a variety of diverse underlying link technologies, path selection in a homenet may benefit from being more refined than minimising hop count. Regarding your criticism about people pitching their favorite routing protocols, you seem to be doing precisely that, so the criticism seems a bit unfair. The responses you have been hearing seem like legitimate attempts to address points you have raised on a technical level, not mere advocacy, and it is unfortunate that you would suggest otherwise: I haven't actually seen you raise any technical points in favor of IS-IS, which you seem to be advocating. ___ 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] Routing protocol comparison document
It seems, in each case, that the word RECOMMEND is far superior to MUST. If I connect two ports from the same router to the same LAN, I really don't normally want them in different subnets (although from a specific reason I might choose that). MIF tells us that we can enumerate members of the same subnet on different physical media in certain cases. While that is true, to my small mind it's not a great configuration from a routing perspective. I would indeed RECOMMEND that different ports on the same router be, in the normal case, connected to different subnets, and I would RECOMMEND that a small simple network be kept as small and simple as meets the design requirements of its operator - which in a home network, is the occupants of the home. If the person is trying to (as I do) connect things that don't move, like TVs, using wired media and connect things that do move using wireless, or to route high volume data by different paths than occasional data flows, there exist requirements that probably don't belong in a document like this, but need to be configurable by a clueful operator. I'd stick to RECOMMEND, and make it clear that the recommendation targets the general case. From: homenet [homenet-boun...@ietf.org] on behalf of Joel M. Halpern [j...@joelhalpern.com] Sent: Thursday, February 19, 2015 11:36 AM To: Ted Lemon; Mikael Abrahamsson Cc: homenet@ietf.org; Juliusz Chroboczek Subject: Re: [homenet] Routing protocol comparison document I would note that RFC 7368 says that simple Layer 3 topologies involving as few subnets as possible are preferred in home networks. I presume this is reflective of WG agreement. While it does go on to note that multiple subnets are sometimes needed, mandating that each physical port on the access router be a distinct subnet (much less extending such a mandate further in the home) seems to violate this agreement. Yours, Joel M. Halpern On 2/19/15 1:11 PM, Ted Lemon wrote: On Feb 19, 2015, at 12:33 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: Sure, ISIS could be made smarter when it comes to this, but it all comes down to what the requirements are. Right now when we started to evaluate routing protocols, people started pitching USP for their perticular favorite, and we found out we weren't even on the same page when it comes to requirements, and even what a homenet looks like. I think it is you who are not on the same page, not the working group. The working group recently published a document describing our goals, RFC 7368. Many of the points you have raised as supposed points of disagreement are addressed in the document, although I will admit that it is not always obvious that they have been addressed. The case of routing over Wifi was discussed at length; the text referring to it in the document is here: Due to the use of a variety of diverse underlying link technologies, path selection in a homenet may benefit from being more refined than minimising hop count. Regarding your criticism about people pitching their favorite routing protocols, you seem to be doing precisely that, so the criticism seems a bit unfair. The responses you have been hearing seem like legitimate attempts to address points you have raised on a technical level, not mere advocacy, and it is unfortunate that you would suggest otherwise: I haven't actually seen you raise any technical points in favor of IS-IS, which you seem to be advocating. ___ 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] Routing protocol comparison document
On Thu, Feb 19, 2015 at 7:18 PM, Ole Troan otr...@employees.org wrote: there are very few shared media around anymore. I don't think I've ever been connected to a 10base5. why should the IP subnet model emulate a shared medium, when the physical topology is a star. wireless with security is also a star topology, with a unidirectional broadcast channel. Unfortunately on layer-1 both are still broadcast... you send a unicast, it might interfere with anyone else in range. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On 19.2.2015, at 11.28, Steven Barth cy...@openwrt.org wrote: On 19.02.2015 10:00, Dave Taht wrote: hnetd exclusive of the library dependencies (which I could easily run a sloccount for, also, if you care) d@nuc-client:~/git/hnetd$ sloccount --personcost 11 generic src test openwrt SLOCDirectorySLOC-by-Language (Sorted) 12936 src ansic=12936 5806testansic=5806 417 generic sh=417 99 openwrt sh=99 As a rough estimate of those 12-13 KLOC only about one sixth should be related to DNCP. So I very much doubt that hooking it up to a 3rd-party daemon for topology/TLV-management would make any noticable impact. Do also note that the current codebase _does_ include the ‘routing’ part too, smirk.. (from dncp-00 branch): src/dncp*.[ch]: 2.7k LoC the rest: 12.5k LoC (’the rest’ seems to be gradually growing but includes e.g. both supported platforms’ C code) src/hncp_routing.[ch] has 309 lines of code, but it also does routing protocol election (that is being phased out but remains implementation-specific, as current $FOO routing protocol is not really usable in the real world). Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 19, 2015, at 2:43 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: If people are making routing protocol decision based on the fact that they think most of the homenet links are going to be current incarnation of 802.11, then we're lacking consensus on a lot wider range of requirements than just the routing protocol. We have different opinions on what homenet actually is and what it's going to look like. Mikael, it is common practice to do air-to-air bridging on home networks now. We have discussed whether we want to support this in homenet, and concluded that we must. You are the first person as far as I can recall to suggest that this was optional. Yes, we do need a routing protocol that works well when some of the transit networks are wifi networks. This is not an edge case. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 19, 2015, at 6:41 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: Basically, Dave Taht and Jim Gettys have been working a lot in these marginal networks. They have a lot of experience. Personally, I don't see their kind of networks as something Homenet needs to support. I can see us needing to support a few wifi bridging hops, but what they're referring to is a quite different beast. I think it's reasonable to assume that the network will be somewhat marginal; if it's really seriously marginal though maybe the right thing to do is have a UI for reporting that to the user so that they can try to fix it. But we want it to work to the extent possible regardless, because we are targeting end-users who may not be competent to respond to UI indications of that sort. Dealing with marginal networks obviously isn't something that's going to happen in an apartment in Stockholm, but it's pretty easy to imagine something like that where I live out in the country, and both Dave and Jim have similar situations. This is exacerbated in my case because we used a lot of building materials with metal foils in them, and that messes with radio propagation. I think in Dave's case it's just distance. The point is that I can completely understand your skepticism about this, but there's a reason why some working group participants have been pushing for functionality in the more marginal cases. I don't think HNCP has a particular problem here, but maybe Markus can speak to that. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 19, 2015, at 3:52 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: For instance the security work now being done on HNCP. Does ISIS already offer the same functionality? I can't evaluate security very well, I don't know how many active in this working group that can. I would rather use an already standardized mechanism for doing this. IS-IS is a routing protocol, not a configuration protocol. Its security needs are completely orthogonal to what we are doing in homenet. HNCP can probably provide the tokens required to do IS-IS security, but IS-IS doesn't bring anything to the table as far as homenet security is concerned. This is basically a red herring: Babel as far as I know doesn't bring anything to the table either. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Thu, 19 Feb 2015, Mikael Abrahamsson wrote: Because if we're trying to support marginal performance mesh networks that might change all the time, lose packets, drop multicast packets randomly, etc, then those requirements need to be brought to the discussion. Basically, Dave Taht and Jim Gettys have been working a lot in these marginal networks. They have a lot of experience. Personally, I don't see their kind of networks as something Homenet needs to support. I can see us needing to support a few wifi bridging hops, but what they're referring to is a quite different beast. Mesh networks are not necessarilly 'marginal'. They're about extending range and mobility. Antonio Querubin e-mail: t...@lavanauts.org xmpp: antonioqueru...@gmail.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Thu, 19 Feb 2015, Gert Doering wrote: We're not talking about a routing protocol for every possible use case here - we're talking about a fairly well defined environment (aka fairly small number of devices, IPv4 and IPv6 only, and implementations constrained by lack of clue on the manufacturer side). Well, to further explain my concern regarding that and current approach, I now see that current proposals is to have the HNCP and $ROUTINGPROTOCOL split. If we choose Babel, then we've locked outselves into this split and HNCP needs to be extended to handle every future functionality needed since babel can't do much more than it already does. For instance the security work now being done on HNCP. Does ISIS already offer the same functionality? I can't evaluate security very well, I don't know how many active in this working group that can. I would rather use an already standardized mechanism for doing this. It's been a while since the decision to create HNCP (which was originally designed so it could work inside a TLV carrying routing protocol) instead of carrying the required homenet information in the routing protocol. The basis for this decision, is that still true (that the routing protocol WGs and implementors refused to accept the TLV types needed and the APIs needed)? It's been what, 1.5-2 years since then? We've already noted that HNCP looks awfully close to a link state protocol and duplicates quite a lot of of functionality. There is talk about how complicated ISIS is. How complicated is DNCP/HNCP going to be when we're done with it? How many LoC is it now? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Thu, 19 Feb 2015, Pierre Pfister wrote: - There is a delay between the assignment and the actual use of a prefix. This is called ‘Apply Delay’ in the prefix assignment draft. I don’t think routing based on assigned prefix TLVs is a good idea because you would not try to handle assigned prefixes collisions correctly. Hi, I was not proposing to use the HNCP TLVs for routing. Actually, I wasn't proposing to change the internal use of TLV movement much at all in HNCP, I was proposing to move them to IS-IS and use that to synchronize them instead of using the current transport. I do not see the fundamental difference in syncronizing TLVs between machines by means of HNCP (trickle based) and by means of a link state protocol (ISIS). -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Also, currently most routers consists of mostly L2 high speed forwarding, with some L3 thrown in between two ports (the WAN port, and the 5th internal port to the 5 port switch chip with 4 external ports). With homenet, all this changes. Now all ports need to be L3. I'm possibly missing something, but I see no requirement to perform L3 routing between the LAN ports. What platforms do the current implementations of Babel support? The reference implementation supports Linux and multiple BSD variants (tested on OpenBSD and Mac OS X). The Quagga implementation supports whatever Quagga supports. At any rate, it is portable code -- making a new port consists in writing a small number of platform-specific functions to interface with the kernel. Do we really believe people are going to use wifi links to connect devices within their homenet? Yes. The ability to simply and cheaply extend one's wireless coverage is one of the killer features of Homenet, and one that can be easily explained. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Thu, 19 Feb 2015, Toerless Eckert wrote: That's because there has been no requirement to do so, most of the time. Basically a device has been sold with a certain amount of features, and this featureset hasn't changed over time, thus there is no need to future-proof. I see this changing. What are the indicators you see ? I see people starting to talk about putting sandboxed applications on the HGW:s, so you don't need a new box for each vendor application. I also (in NDA talks with some HW vendors) see mobile SoCs trickling down into the router space and these have very different performance numbers compared to the current low-performance devices. I also see operators wanting to deploy new services quicker than they can today when in the current HGW incarnations most of the functonality is set at initial procurement time and then not much more happens over the 5+ year lifetime of the device. How many commercial vendors are really selling boxes with OpenWRT (no homenet) ? To me, OpenWRT (without homenet) has already a lot of benefits over those vendor specific SW on home routers, but seemingly that hasn't helped much to proliferate OpenWRT into commercial offerings. I know commercial offerings that use OpenWRT. Unfortunately they are usually tied to the SoC vendor kernel because of device-specific board support packages. I see these vendors putting pressure on the SoC manufacturers to stop doing this, because if you want to deploy new services but you're locked to a Linux 3.2 kernel because otherwise your packet accelerator won't work, this is a pain point. So just the way it was really hard to buy linux compatible hardware in the 90ties (been there, felt the pain, had to buy 3c509), this is less of a problem today, and what I see is that more and more operators want to get deeper into their HGWs and control the software development themselves over time. See Free.fr for instance. In the project I am, we're not going to choose a device were we don't have significant control and can roll out own images and put on the HGWs. Just having looked for a good router for homenet, i am not really happy yet with the choices available. Especially because i'd like to also run a bit more than just basic routing. = 32MByte memory, = 16MByte flash for example. Still seems to be a very limited set of choices. Absolutely. Most devices sold today both to operators and end-users are sell and forget. I am saying I am seeing this trend changing, albeit slowly. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Thu, Feb 19, 2015 at 08:43:26AM +0100, Mikael Abrahamsson wrote:
* While ram and flash have grown to be essentially free I really dont
see home router and cpe makers rushing to embrace slower languages or
bigger flash and memory requirements anytime soon.
This worry has been raised by others as well.
That's because there has been no requirement to do so, most of the time.
Basically a device has been sold with a certain amount of features, and
this featureset hasn't changed over time, thus there is no need to
future-proof. I see this changing.
What are the indicators you see ?
Also, currently most routers consists of mostly L2 high speed forwarding,
with some L3 thrown in between two ports (the WAN port, and the 5th
internal port to the 5 port switch chip with 4 external ports). With
homenet, all this changes. Now all ports need to be L3. This is a huge
change both when it comes to bandwidth needed from the CPU to the ports,
and also L3 performance needed. This will require home gateway
manufacturers to make very different devices.
Sure. But does homenet give them the right user benefits to make it
worth their while ? Especially for gear that would not be OEM'ed by
SPs but in retail.
How many commercial vendors are really selling boxes with OpenWRT (no
homenet) ? To me, OpenWRT (without homenet) has already a lot of
benefits over those vendor specific SW on home routers, but seemingly
that hasn't helped much to proliferate OpenWRT into commercial offerings.
We also have the (previous) mobile SOC:s trickling down into the home
router space, and these are very price/performance efficient.
Just having looked for a good router for homenet, i am not really happy
yet with the choices available. Especially because i'd like to also run a bit
more than just basic routing. = 32MByte memory, = 16MByte flash for
example. Still seems to be a very limited set of choices.
Do we really believe people are going to use wifi links to connect devices
within their homenet?
Yes. Simply to extend reach. And if i understand it correctly,
If you have the typical setup:
Internet - router/AP wireless1... client/bridge/AP wired
wireless2
AFAIK, this setup is typically sometthing that only works well if
router/AP and client/bridge/AP come from same vendor due to the complexitites
in AP/bridge looking like multiple clients on wireless1. So it
looks like a good opportunity to highlight how homenet would turn
client/bridge/AP into client/router/AP and eliminate those problems,
allowing vendors of such devices to much easier get added - without
expecting that router/AP is upgrade/changed.
Cheers
Toerless
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Thu, 19 Feb 2015, Juliusz Chroboczek wrote: Is the load from routing protocols we're talking about likely to have any noticeable effect on the the forwarding rate? Here are the figures given by H. Gredler on p.266 of The Complete IS-IS Routing Protocol for a Cisco GRP 1200: Routers Links SPF time (ms) 100 250 4,80 200 500 12,42 4001000 31,22 6001500 52,94 8002000 76,67 1000 2500 101,94 I have no idea how a Cisco GRP 1200 compares to a non-superscalar, 250 MHz MIPS processor with a tiny cache. Cisco 12000 with the original GRP (I guess this is what the book is referring to) sees to have used a 200Mhz R5000 processor with 512KB L2 cache. The platform was released back in 1999 if I remember correctly. From: http://www.cisco.com/c/en/us/support/docs/routers/12000-series-routers/40060-12000-boot-process-40060.html cisco 12410/GRP (R5000) processor (revision 0x01) with 524288K bytes of memory. R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache On modern intel based platforms today, SPF calculations typically take a few milliseconds, even though the networks have grown larger. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Thu, 19 Feb 2015, Juliusz Chroboczek wrote: Also, currently most routers consists of mostly L2 high speed forwarding, with some L3 thrown in between two ports (the WAN port, and the 5th internal port to the 5 port switch chip with 4 external ports). With homenet, all this changes. Now all ports need to be L3. I'm possibly missing something, but I see no requirement to perform L3 routing between the LAN ports. Really? Then you and me have fundamental difference in opinion what topologies we want to see in homenet. I want to see fewer broadcast domains. If we're going to keep the large L2 domains, then we don't really need homenet at all. The only reason to have homenet is if you're going to have a substantial amount of routers in arbitrary topology, that actually route. If we want to L2 switch most traffic, then we have made homenet unncessarily complex. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
