Tuesday 04/03/2014 9:00 Chairs: Mark Townsley & Ray Bellis Agenda: 09:00 Administrivia (5 min) 09:05 Tim Chown - draft-ietf-homenet-arch-12 (15m) 09:20 Daniel Migault - draft-mglt-homenet-dnssec-validator-dhc-options-01 (15m) 09:35 Steven Barth - draft-stenberg-homenet-hncp-00 (30m) 10:05 Markus Stenberg - draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-00 (15m) 10:20 Pierre Pfister - draft-pfister-homenet-prefix-assignment-00 (15m) 10:35 Tim Winters - draft-winters-homenet-sper-interaction-01, and CER ID (20m) 10:55 Open mic on Homenet configuration in a routing protocol (30m) 11:25 Next Steps === WG Actions: 1. Call for authors for a draft to document OAM issues not otherwise addressed in draft-ietf-homenet-arch to satisfy the Ops Area ADs. 2. Good support for adoption of draft-stenberg-homenet-hncp === Session Transcript 04/03/2014 09:00 - Chairs introduction, state your name, blue sheets, .... 04/03/2014 09:06 - Homenet Architecture - Tim Chown Hoping that we are there, that -13 will pop out and the last discusses (2) will be cleared. Do need your comments on a couple of the changes Total 70 discuss and comments from the IESG. 4 categories where major changes happened, walking through what those were. Multicast (slide 3) - any comments? Dave Thaler: Clarify that we perhaps should say "link media types" not just "media types"? (text on slide 3) O&M (slide 4) - any comments? None heard - call for authors for new doc Routing (side 5), overview of changes made - any comments? None heard Slide 6 "On reusing existing protocols" any comments? None heard Slide 7 "On multiple routing protocols" any comments? Mark Townsley: This was discussed and iterated between chairs and the RTG ADs. Lee Howard: Ideally one or none routing protocol is a better phrasing? Is the requirement that they all run the same routing protocol, or is the requirement that they can all route to each other? Mark Townsley: The context is "one routing protocol" even if they are able to route between each other there'll be one protocol enabling that. There's a protocol enforced that makes that possible. Lee Howard: I do not think that anyone can read what is in the slide, to be what you just said. Mark Townsley: Are you agreeing or disagreeing? Lee Howard: Disagree, this is not the exact requirement that we have We need mechanisms to ensure that all hosts can reach each other, not more. Mark Townsley: Take it to the list Dave Thaler Agree with the first point, should say at most one protocol. For simple topologies "no protocol needed" Need to see the preceding context to know if that is already constrained. Mark Townsley: Agree, this needs to be explicit. Lorenzo Colitti: I think that I'd say "Multiple routing protocols in the home, are you on crack?" Look at any tier-1 provider, they run more than one protocol only in particular situations.....and it is not simple Mark Townsley: Take this to the open mike. Mark Townsley: As long as "zero" is a choice, Lee and Dave's issues are covered. Lorenzo's issue is covered - supporting more than one protocol doesn't mean using more than one protocol at the same time. "On the "Complete View" (Slide 9) any comments? Michael Abahamsen: Do we really want the link metrics in there, why not "optionally link metrics" Mark Townsley: I see those as "such as" even though they do not say this Dave Thaler: This is basically saying that we require the RP to be a LS protocol. Is that over-constraining, or is that what we want? Lorenzo Colitti: says +1 from his seat Dave Thaler: This may not be appropriate in arch document, but a viable choice for the wg Fred Baker: This does constrain the solution space, wonder what the reason is for constraining this? (Agree with Dave) If I was to suggest text it would be something like "The thing should be able to figure out the next hops to get to the destination" (back to presentation) LLNs (10) any comments? None heard. "On configuration information" (11) comments? None heard "Default allow/deny 3.6.1" (Slide 12), comments? Lorenzo Colitti: I think that's a fine way of saying nothing. (Giggles, and Townsley suggesting that this was a good indicator that we were done) (back to presentation) Will now push out -13, will try to fold in comments received today, and include. === 04/03/2014 09:20 Danel Migault - Homenet Naming DHCP Options Same set of slides discussed in DHC working group, but will discuss them slightly differently. Mark Andrews: I do not trust any ISP with my private key, I do not put my private key out to anyone Daniel Migault: You can sign on the CPE and push it out Mark Andrews: Then do not put it where you put it on the figure in the slide (insert number), it's wrong. ???: Do you trust the end user to handle private keys? Mark Andrews: Yes, I do trust the home user to do that. Let the CPE generate the key, signature, and publish the record. Ray Bellis: You said "I don't trust the ISP with my private key', but in this case they use their key? Mark Andrews: It is my data, it's me who needs to sign, I own the reverse. It's my name, so I need to sign. Ted Lemon You are talking a different use-case. The use-case where you want to publish your own info in your own domain, that's different from what we discuss here. Doesn't really matter to them how the management is, for most users. We do need to address both of these use-cases Mark Andrews: The CPEcan generate a signing key, can publish DS records, we have drafts on how to do that and completely automatic. So, for the home use, this is completely automated, the home user needs to do nothing. Ray Bellis: Let us not rathole on a DNSSEC question. Some people will be quite happy Mark Andrews: It's bad policy Stuart Cheshire: Going to agree with Mark. All of that data, if that comes from the home-CPE and sent insecurely to the ISP, then it is subject for tampering. So you need to sign it, and sign it at the source. Stuart Cheshire: All this depends on trusting the information from the CPE, so why not trust it completely rather than have two sources of Ole Troan: Go back and look at requirements. How do you handle multiple ISPs for example. I question that DHCP is the right choice, it ties you down to a provisioning architecture between the ISP and the CPE. I think that we should go back and look at the architecture and the requirements Daniel Migault: When we designed the DHCP options, we had to make some assumptions, to make them implementable Ole Troan: I disagree with your assumptions Mark Andrews: The option is saying "the ISP is willing to be secondary", you populate the NS records into the zones, and push them out to both of them. There is no problem, this is a service the ISP offers that you can use or not. Andres Sullivan: I am totally not clear on something. Inside the homenet, you have a split-horizon scenario here. Internal and public. What's kinda weird is that you on the inwards looking zone need to do DNSSEC, so with two different DNSKEY set, you may have a cache contamination problem? We had a failed approach on this in DNSEXT. I think that you need to spend a lot more time working out how these things work, or say "don't use DNSSEC on the inwards zone" or you have conflicts. If I carry around a laptop and it has a cache and sometimes I access from the inside and from the outside, I will end up having bogus results ???? I have no problem with doing signing on CPE, but these days a CPE is a throwaway device and you plug in a new one and expect it to use. Transfer private key, how? Michael Richardson: Let me offer a different point of view: ISP owns and operates all CPEs. May argue that in that case it doesn't matter where it happen. Still 2 or 3 advantages or points of signing on the CPE 1) What Andrew said about caching 2) For the customer that does want to control their own zone, it's exactly the same to the ISP as those who do not 3) When a three-letter agency comes about and want them to change the keys, if the keys are on the ISPs server they do it - but if the keys are distributed, then the legal warrant needs to be for each individual piece of equipment - plausible deniability. (presentation continued) Mark Townsley: Need to take feedback on the list, all you guys with opinions take them to the list. Daniel has been very attentive and wants to continue to be that Mark Andrews: DNSSec times stamp fields, make it binary Mark Townsley: Take it to the list === 04/03/2014 09:43 - Steven Barth - HNCP Acee Lindem: We are going forward with auto-config draft in OSPF, there is a solution where you can avoid on a broadcast link the wait time Somebody commented on this. The real issue was, these supporters of other protocols didn't want to hone in on one. That would be my assessment, Mark Townsley: If we are going to talk about the core routing issue, we have time on the end David Lamparter: Should be careful not to make this a requirement (presentation continued) On or around slide 6 Juliusz Chroboczek: This is the stateless subset of DHCP, right? Steven Barth: Yes Mark Townsley: Let's limit to technical questions to this I-D, not philosophical question Barbara Stark (AT&T) You talk about an algorithm to discover external, but how about internal? Steven Barth: We assume that if it is not external, then it is internal. Grace period, if during which we get prefix etc., we assume external, otherwise we assume it is internal. Barbara Stark: Do you do configuration by the user as to internal / external? Some users do want to create a tree topology on the internal side and want the WAN port to still be internal. Juliusz Chroboczek I like this drafta lot and am really impressed. You didn't mention that your implementation is a complete implementation in OpenWRT, and that is impressive. The I-D might need a -01 before we can understand it. So, if I say something stupid now, it's not my fault, but the draft. Are you not over-specifying things a little. for example, why say "use trickle", why not "We broadcast, and oh by the way we use trickle and it works great"? Also, everything in the document is compulsory, or so it seems. Steven Barth: Not everything is meant to be compulsory, but this is something that we need to work on. Need to separate the "Transport logic" from the "payload logic" for example Juliusz Chroboczek: I am also not thinking about this as a homenet configuration protocol, but it is a little more general. There seems to be no way to express "here's a large prefix, carve as many /64 out of it as possible". Steven Barth: Not in this draft, Pierre's draft later will discuss this. Will not handle here, will hand over to Pierre Juliusz Chroboczek Do we need the "if you do not understand this TLV, don't configure it". Steven Barth: I think we have the rule that if there's some option you don't understand, or use, don't do that, for prefixes, but we probably have not done that for general TLVs, good point, will look at it. Juliusz Chroboczek: The protocol here implies that the config daemon starts the routing daemon, which is wrong. The routing daemon starts at boot, and the config daemon runs in parallel, that is how we do, and that contradicts your protocol. Steven Barth: What we do is to advertise which protocols are supported. Can be discussed. I do not think that you want to really run multiple protocols, but advertise and disable those that you do not use. Acee Lindem: I thought it was not over-specified but under-specified. Had to use a lot "well, it must work this way", so I think that it could use more state machines etc. I think Trickle is a good idea, contrary to Juliusz's comments. Trickle is very light weight, and the consistency rules doesn't specify how/when exactly to retransmit. Need to be more specific here. Erik Kline: I like the use of Trickle. I disagree that the routing needs to be started from config protocol, it's the other way around Two questions, first, what testing with various ISPs did you do? Did you do any real-world testing, etc? Steven Barth: Haven't tested that much on different ISPs, test for working. Open to real-world testing now. If you can come up with a better way to the userclass stuff, feel free Erik Kline: Second question, on the DHCPv6, are you also redistributing the source of the data? If you don't you will not succeed if you have two upstreams. Steven Barth: We have one TLV per uplink, each of which contains multiple TLVs with the prefixes, ???? supplied. At the moment, we do merging, throwing everything together when pushing downstream Erik Kline: You can still redistribute the origin Markus: Every router on the home network will know about every external link. In principle, all routers in the homenet will have all this information. Lorenzo Colitti: Just pointing out that interface is not the correct granularity (on Discovering Borders slide), it should be "next hop" in case of mixed interfaces Steven Barth: Depends on how much you want to do.....if the user does such a horrible thing as creating a mixed interface, it should at least not break. John Brzozowski: Agree with Erik's comments === 04/03/2014 10:17 Multi-router Zeroconf - Markus Stenberg (presentation until the end) ??? Seems that you no longer use OSPF, are you using trickle? Markus Stenberg: Yes, we do not say how things are encoded, etc., routing protocol agnostic. Ralph Schneider: In this solution has AppleTV mirroring been tested with this....? Markus Stenberg: I do not own an AppleTV Stuart Cheschire: AppleTV is a special case because of music and movies and copyright. That muddies the waters, I want to make that clear as it is a question that comes up a lot. There's a bit of a conflict there, when you use - say - an AppleTV to show presentations in a meeting room -- whereas a student in a dorm-room sharing movies with the whole university. There are legal and non-technical issues, which I wish that the AppleTV didn’t have, but has to have Tim Chown: Encourage you to have a look at the DNS-SD requirements draft, and get your feedback from that. === 04/03/2014 10:26 - Prefix and Address Assignment - Pierre Pfister Lorenzo Colitti: I have two comments about the new addition The nice thing about the previous draft was that it was stateless, with recovery mechanisms when things went unplugged etc. Go back to slide 4, that stuff is stateful, so you end up with, when stuff crashing, state sitting around. To make this work you need synchronization and recovery etc. There's a failure mode that we cannot handle, I think that we should not go there. Pierre Pfister: How do you suppose we support IPv4? Lorenzo Colitti: With NATs, that's a fine way to do it, it is consistent with established practice. NAT will work all the time. We have to make things fail-safe. You do not have straight shot to the Internet John Brzozowski: Encouraging NAT is a bad idea, really. We're not trying to make v4 awesome like v6 is, but lets not try to intentionally make it worse Mark Townsley: In our charter, we said that we would design for v6, and where applicable also use that design for v4. We're defining the v4 congruent approach. Lorenzo Colitti: No objection with v4, but with that we started with a stateless solution and now we put state into it. Without having considered our failure modes. If we want to do prefix coloring, it should be something in the homenet configuration protocol, not this. We decided a long time ago not to use DHCPv6 inside the home due to the failure modes. You want stateless stuff you can support. Stateful DHCPv6, without support for failure modes, has failure modes - if we go there, go there with eyes open. No objections to support DHCPv6, but do it correctly. Mark Townsley and Ray Belis: Let's take this to the list Ted Lemon: We have some really great technology to deliver IPv4 over IPv6 - NAT64, may be worth looking at that, may satisfy Lorenzo. Acee Lindem: I agree with Lorenzo here, don't even go there. Lorenzo Colitti: We cannot support prefixes shorter than /64, without talking to 6man Mark Townsley: Routing architecture should be agnostic to that, it's not a routing problem Tim Chown: I agree with what Lorenzo just said. === 04/03/2014 10:46 - Homenet Design Team - Timothy Winters Question to last slide by some gentleman who didn't state his name and go to the mike - not recorded. === 04/03/2014 10:51 Chairs summing up.... Different options now seen by WG: OSPF for routing and configuration, or HNCP for minimalist routing now, with full-blown routing TBD. For these, there is now running code. And then, there's "something else" that can be thought up Need to move to solutions now. Chairs spoken with ADs who considers that were now done with architecture, even though it needs to go through the final stages of the process, and AD would like to see us move forward to solutions. First thing I want to ask is: - Can we ask these questions? Also it's open mike, let's talk about that, go. Juliusz Chroboczek: This is a little misleading. HNCP does not exclude OSPF, point 1 should be "for combined routing and configuration" Lee Howard: The problem I have always had with OSPF is that I have spent a lot of time studying OSPF for certification, and that was painful. Idem spanning tree. I agree that the arch doc is 99.9% done. I like the idea of HNCP - although it is a little too new for me to have a fully baked solution on, but I lean towards that. To the 2nd half of number 2 (on the chairs slide) I think that we need to select a routing protocol Michael Leibhansson I like HNCP for short-term, it enables us to test mechanisms etc. I would like to see a technical analysis of the different routing protocols, to see how large TLVs they support (may be a problem, say, TLVs larger than MTU size)? Do we need a requirements list before we can make this choice, we need to do that analysis to make informed choice. Mark Townsley: My only objection is, that while it was 2 years to bake the arch document, if you suggest 2 years for a requirements document then I do not like those perspectives. It is a good point that if you want config to be supported in different types of structures, you need to know the limits of the protocols etc. Brian Carpenter: Lets take the architecture doc as a done deal. Not actually sure that it is a requirements or problem statement, but even if it is, I still cant decide on the options 1-2-3 based on what I have, depends on what the architecture calls for. I do not think that we can make that in this meeting in real time today. Need the analysis done. Instinct is "not number 3, please" Analysis needs not be documented as such, but we need one more phase of analysis, the two approaches. Barbara Stark Please just one, I can't tell you how complicated it would be if there has to be sone previous negotiation. OSPF, HNCP, .... HNCP is actually two things, if you pick that, you may never pick a full-blown one. The history of what happens when people pick the simple thing, they often end up extending it and never get the 2nd part of two, that may never happen. But, I do not have the knowledge to care between OSPF or HNCP Dave Taht: Strongly support HNCP. I also have a plea, it really helps to have running code for evaluating options, to test edge cases etc. Michael Richardson: I am thrilled to see HNCP, but I think I missed the presentation from the people who presented it about what they couldn't do with OSPF that triggered them to do HNCP. Markus Stenberg: The main thing that HNCP is not that we couldn't do everything in OSPF, but more a layer 9 solution: some want one protocol, others another and yet others none. If you run no printing(?) protocol, you can't use it for autoconf. David Lamparter: With OSPF we had a lot of discussion how to do src-dest, prefix assignment, ..., but I am not aware of discussions of how to encapsulate DHCP options, and I do not think that that's actually difficult. Think that unless we go with HNRP, I think we're stuck with routing protocols somewhere. I believe that part of the problem with OSPF is purely a perception issue. John Brzozowski: 3 is definitely out, if that happens we pack up and go. Like the idea about HNCP, it allows for the incremental approach. Also, concurs with Barbara that "having n routing protocols at home" definitely is scary. Acee Lindem: I pretty much agree with Markus that we can do anything we want with either OSPF or HNCP. Seems to be lot of filibusters whenever we want to pick *an* IGP. Another advantage of HNCP is that it doesn't try to move a protocol that's deployed in so many places. I wouldn't be opposed to HNCP. Lorenzo Colitti: I agree with John, #3 is not good. I firmly believe that zero is not an option (zero being "no routing protocol") I believe that the number of protocols we need is exactly one. 1 vs 2, I kinda agree with Acee about the velocity, HNCP allows us to move faster than asking the OSPF Gods to affix their stamp of approval. Another thing is, that we need more than routing, I think that it doesn't make sense to do generic configuration in OSPF, we're going to have those 23KB blobs passed around in OSPF. Fundamentally its a TLV, but it's not really designed for that at the same time. So I guess I am in favor of option 2. I think that the poor-mans-link-state that HNCP does is probably fine. Ole Troan: I would much rather that we adopt HNCP, and a routing protocol for routing. Ted Lemon: Although the ISPs certainly can deliver the edge router, homenet needs to go inside the home, multiple routers, that the customers bring themselves ????? I do not like "full blown routing TBD". OSPF is way too complex for people's homes. I propose RIP, I do not like to complexity peoples homes. Juliusz Chroboczek: Add to what Markus was saying about why nervous about configuration in OSPF. Everybody knows how to debug a configuration protocol. There are people who know how to debug OSPF. Nervous about mixing the two, want modular solution. Think that there should be no problem implementing source-specific routing in RIP. OSPF, also, with a little more effort. Agree that there should be one routing protocol, but favor separation between routing and configuration Henning Rogge: Not crazy about the potentially messy code-base that can result from mixing routing and config. Worry about the question "how do I turn off the routing part" of such a mixed routing-config component Acee Lindem: One think that I thought about. With HNCP you can have the information defining the scope of the flooding, whereas in a routing protocol the scopes are link, area, routing-domain -- or, you need to roll your own. Mark Townsley: Seems that I understand that we may not have all the options, but perhaps can we eliminate some of those that we don't want. Dave Thaler: You said that there's different variations of two, as some of those are in category three. Ted Lemon: It seemed like that there were some who wanted HNCP + something specific, others who wanted HNCP + didn't have something specific, and some wanting OSPF. Ask question, but make it clear that you do not commit to any specific variation of option 2 Dave Thaler: Suggest you ask the questions "For config, should we use 1, 2 or 3" Only scope for configuration. Then, ask the same for routing. Mark Townsley: Right, will do that Humming 1. OSPF for configuration, hum (almost none) 2. HNCP for configuration, hum (strong hum) 3. Something else for config (very quiet hum) Conclusion: strong support for 2 Curtis Go,..: Couldn't that be "OSPF as a must, something else as a MAY"? Ted Lemon: There should be an "I do not know yet" option for routing. Teco Romeo: What if I want just one, but don't care....? Mark Townsley: We may not be ready to make the choice on routing. Could we solidify the support for HNCP by adopting it as WG document, then make it what we want? Steven Bath: Would rather suggest that we agree on the number of routing protocols first (zero, zero-or-one, n) Ray Bellis 1. Do you support zero or one protocol (strong hum) 2. Do you support 2 or more protocols (weak hum) Teco Boot: HNCP should enable many different protocols, but HOMENET should chose one. May be space for use HNCP wider. Ray Bellis: Yes, homenet profile. Michael Abrahamsson HNCP for WG, is that this I-D, or all 4 drafts? Lee Howard: I want a few more weeks before WG call on taking HNCP to WG Ray Bellis: We will take this to the list Ted Lemon: Not prepared to hum on HNCP routing. Mark Townsley: Reflect consensus on HNCP by moving it to WG, hum (good hum) Those who don't know yet (weak hum) Against (no hum) Shown support for WG draft Non-significant support for "don't know yet". No support for "don't bring to working group" 04/03/2014 11:30 - Meeting closed