Re: [homenet] Moving forward.
On Wed, 5 Aug 2015, Teco Boot wrote: Another 2ct: during convergence, there should not be looped packets. Reasoning: especially on shared media such as wireless, looped packets effect RP behavior and other user traffic badly, and thus result in bad user experience. When I was in TSVWG they said that there were 4 different "QoS" classes on wifi. The default is to run the routing protocol in the highest QoS class. Thus, I don't see this as a huge problem, the routing protocol should always be treated with the highest priority. I expect HNCP to be run in the same class as well. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Tue, 4 Aug 2015, Ray Hunter wrote: As someone who spent rather a lot of time wordsmithing Section 3.5 of RFC7368 into something that could reach rough consensus, I find this discussion rather depressing. Section 3.5 was the list of requirements we could agree on when the architecture document shipped. I've been on record as being agnosting in the choice of routing protocol, and hope(d) the DT would deliver us from stalemate, so I remained silent. We have been trying to address all objections to ISIS by addressing the few things that were not already there. Yet, people keep arguing. Now I see a lot of super-heavyweight industry names seemingly failing to grok Homenet in general, and specifically the use case of WIFI as a home backbone. What makes you say this, especially in light of what was presented at the last IETF? But if we go for IS IS we're apparently going to have to wait (perhaps forever) to get L3 routing over WIFI working/ stable. Something that we've pointedly failed to do in professionally managed office networks in the last 20 years. Again, what makes you say this? I keep hearing that babel is loop free and that this is a great feature. My take on that is that it's a great feature when wifi just sucks and keep going bad and keeps going away and coming back, and you're happy if a few packets are delivered once every now and then. When I say this, Juliuz says I am silly. I make sure my wifi works 99.9% or more of the time. Unless it always works, it's useless to me. I don't see why isis+wifi-backbone couldn't be used in my home (not that I will do that, but if I would). So again, with basic features like setting the metric depending on interface speed and type (which has been around for 15-20 years for routing protocols in all kinds of places), what is it that babel would actually give us in a decently working homenet with wifi backbone? ISIS will handle just fine when people unplug and plug cables back in. Field engineers have been doing this (badly) forever, ever since people started doing computer networking. I will yield that babel is better in a mesh network where all bets are off, but is that really the kind of network we expect people to have? The Internet is moving towards supporting real time communication that must always work. Yet, I keep hearing that this isn't the homenet we're expecting to have? Or what am I missing? On the flip side I don't see barriers to Babel running on small cabled networks. I keep hearing this. As far as I know, nobody has ever said babel wouldn't run on cabled networks. I don't see why this point is repeated, nobody is arguing with this point. In short: I largely agree with Ted, but I see the WIFI backbone use case as a killer differentiator for Homenet (regardless of the final choice of routing protocol). If IS IS can't deliver on that, then it's a real miss. It can. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
> Op 4 aug. 2015, om 20:22 heeft Dino Farinacci het > volgende geschreven: > > IS-IS hellos are sent by default roughly every 10 seconds. CSNPs to keep the > link-state database in sync is sent every 10 seconds. The sample or default timers are not optimal for todays wired links. We cannot trust on lower layer state (driver issues, switches). I suggested (hello=1,dead=4) some years ago. Acee responded this is topic for further discussion. http://www.ietf.org/mail-archive/web/homenet/current/msg01961.html Resulted in "Minimising convergence time should be a goal" in RFC 7368. At last IETF, Henning hacked olsrd2, now it has better zero-conf and it has SADR. I tested using a homenet scenario (NRL core simulation). olsrd2 converged much faster than ospf6d. Both ran with defaults, as mandatory in homenet. My 2ct on RP requirement for convergence speed: 1-hop convergence should be within 5 seconds, network wide convergence within 15 seconds. Reasoning: this is _additional_ time in the total boot procedure. Another 2ct: during convergence, there should not be looped packets. Reasoning: especially on shared media such as wireless, looped packets effect RP behavior and other user traffic badly, and thus result in bad user experience. Teco ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
> On Aug 4, 2015, at 12:47 PM, David Oran wrote: > > I think Dino was referring to high-fequency non-human events that can cause > links and boxes to flap. Right. If we had route flaps once a minute, I would consider that not often. Dino ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
> On Aug 4, 2015, at 3:29 PM, Michael Richardson wrote: > > > Dino Farinacci wrote: >> Links and boxes should not go down often in a homenet, so there >> won't >> be a high-rate of packets. This, I believe is a safe assumption. The > > I don't agree. > > Cables are plugged and unplugged on a regular basis, and unplug/replug is a > good first "what's wrong with my network" before going to see if the DSL > model is still alive... Now you wonder what the cable on my laptop has to do > with Homenet... well, because my laptop is running virtual machines, and > since I want them on the network, I'd have a homenet daemon on my laptop. > What you describe isn’t “often” on the timescales of the distributed protocols. A human can only plug and unplug things on timescales of seconds, not milliseconds, and I think Dino was referring to high-fequency non-human events that can cause links and boxes to flap. I can’t say for certain, but my old ISIS code would certainly not be unhappy with up/down events on the order of one every second or a few seconds. > Lots of non-technical people unplug all the cables from their router in order > to power cycle it, because... who knows which wire is the important one? > > Old people are never quite sure if the RJ45 is seated properly, I've noticed, > so they might replug each cable a few times over a one minute interval. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
Dino Farinacci wrote: > Links and boxes should not go down often in a homenet, so there > won't > be a high-rate of packets. This, I believe is a safe assumption. The I don't agree. Cables are plugged and unplugged on a regular basis, and unplug/replug is a good first "what's wrong with my network" before going to see if the DSL model is still alive... Now you wonder what the cable on my laptop has to do with Homenet... well, because my laptop is running virtual machines, and since I want them on the network, I'd have a homenet daemon on my laptop. Lots of non-technical people unplug all the cables from their router in order to power cycle it, because... who knows which wire is the important one? Old people are never quite sure if the RJ45 is seated properly, I've noticed, so they might replug each cable a few times over a one minute interval. -- Michael Richardson , 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] Moving forward.
> On Aug 4, 2015, at 11:01 AM, Ted Lemon wrote: > > On Aug 4, 2015, at 1:32 PM, Dino Farinacci wrote: >> I could guess you are referring to the lack of multicast performance over >> wifi. If not, please be clear about “L3 routing over WIFI working/stable” >> means. > > How often does a typical link over which IS-IS operates drop an IS-IS packet? A question for a question. IS-IS hellos are sent by default roughly every 10 seconds. CSNPs to keep the link-state database in sync is sent every 10 seconds. And all LSPs are sent on demand when there is a link or neighbor change. Links and boxes should not go down often in a homenet, so there won’t be a high-rate of packets. This, I believe is a safe assumption. The size of an IS-IS LSP will be a function of not only the number of links and routers in the topology, but any other information that is needed to be conveyed (quite possibly device IDs, names, capabilityes, multicast group addresses). Dino ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
On Aug 4, 2015, at 1:32 PM, Dino Farinacci wrote: > I could guess you are referring to the lack of multicast performance over > wifi. If not, please be clear about “L3 routing over WIFI working/stable” > means. How often does a typical link over which IS-IS operates drop an IS-IS packet? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Moving forward.
> But if we go for IS IS we're apparently going to have to wait (perhaps > forever) to get L3 routing over WIFI working/ stable. Something that we've > pointedly failed to do in professionally managed office networks in the last > 20 years. What is so unstable about it? I could guess you are referring to the lack of multicast performance over wifi. If not, please be clear about “L3 routing over WIFI working/stable” means. Otherwise, IS-IS will send multicast frames pretty much at the rate that ND would. So I don’t know what the big fuss about how multicast control protocols, in general, don’t work well. Dino ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] some IS-IS questions
Markus Stenberg wrote: On 29.7.2015, at 17.35, STARK, BARBARA H wrote: Perfect! Thanks. I'd missed that. Yes, that's exactly what I was looking for. So when the Design Team compares IS-IS to Babel, they really should be comparinghttps://tools.ietf.org/html/draft-lamparter-homenet-isis-profile-00 to RFC6126+RFC7557+draft-boutier-babel-source-specific-01. Well said. Any other IS-IS comparison would involve a hypothetical IS-IS. Since a hypothetical IS-IS, by definition, does not exist, a hypothetical IS-IS would fail thecriterion that requires examination only of existing IGPs. First of all, thanks from me to David L. as well for the document; I love having it around. I think the metric stuff is missing from that at least (although they are 'wide' which helps I guess to express 10 better); so we're dealing with fixed default metric IS-IS configuration here. Yes, but it's still not nailed down. The architecture requires support for "heterogeneous link layers". IMHO That means metrics have to take into account link type, if not measured reliability. Pure hop count won't cut it for Homenet. And default metrics on most IS IS implementations I know default to hop count behaviour (metric of 10 per interface crossed). It seems to be also missing security. Yes. And to echo Barbara, if that is not the plan, now would be good time to update the document. +1 Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
