NEMO WG meeting minutes, compiled by T.J. Kniveton. Thanks also to Alexandru Petrescu for assisting in transcribing the commentary at the WG meeting. IETF69 July 22-27 2007 Chicago === NEMO WG page: http://www.ietf.org/html.charters/nemo-charter.html NEMO Additional Page: http://www.mobilenetworks.org/nemo/ NEMO Status Page: http://tools.ietf.org/wg/nemo/ === THURSDAY, July 26, 2007 0900-1130 Morning Session I - Monroe Note from TJ: I have included some of the pertinent conversations that happened during the presentations here in the minutes. For the full details, you can go to the Jabber logs. Whenever I have a question that is answered, “A:” refers to the speaker who is giving the presentation, answering the question. 1. Welcome, agenda bashing ....................................... 05 mins Chairs 2. WG documents status .......................................... 10 mins Chairs http://tools.ietf.org/wg/nemo/ - Discussion of charter. Question: is former charter in the archive? Answer: There is a link, but it appears to point to the IETF page. I am not sure whether it is available on our web site. NEMO Management Information Base http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-03.txt - MIB has a new version submitted last week and is going into working group last call now. - Prefix delegation: Both drafts are currently expired. There seems to have been little interest shown in implementing these, but we do need to come up with a solution according to the charter. No last call has been issued yet. - In end of 2006, we started working on rechartering of NEMO, so now we have a new charter Mission: collect NEMO requirements for -autombile, -aeronautics, and -personal mobile router use cases. We have received input for all three use cases, and we will go through all of them today. The PMR use case was the most recent to be contributed to the group. - As you may know, NEMO, MONAMI6, and MIP6 working groups are merging into the MEXT wg. The charter is on the mailing list but not yet on the web. 3. Use Case Personal Mobile Router ............................... 15 mins Consumer Electronics NEMO RO Deployments and Requirements Chan-Wah Ng http://www.ietf.org/internet-drafts/draft-ng-nemo-ce-req-00.txt Questions: Suresh - All the nodes may also move to the car's network, without much of a penalty. A: Depends on access network. If you are using a CAN (car-area network), it is a fixed network Suresh: But you're not excluding the scenario where the car network can advertise? A: No. Based on current technology, in initial phase they will be separate links. Anshul Kantawala - Are you talking about going from PAN in one home network to another home network? A: There may be multiple PANs in one home. Gabriel Montenegro - Question on PAN. PMR is the only node with routing capabilities. Do you mean internet gateway capabilities, or routing? You may have a mesh network or is that a MANEMO problem? A: Currently we are not considering a mesh type of PAN. Everyone has connectivity to PMR. Gabriel - Do the PANs need to be fixed? Many of these devices are shared / lent. Is that part of the scenario - constantly changing PANs? A: I don't see significant changes to the scenario when nodes within the PANs are swapping/booting/shutting down. RO should not be impacted. Hesham Soliman - It's important to get terminology and assumptions right for future work. Initial definition is very restrictive. Basically you're saying it's a mobile phone. Please outline the assumptions, because currently these restrictions do not make sense. What is the case you're trying to make, except that we need route optimization? What's a deployment-specific issue for a PMR that's so different? A: Trying to narrow down RO problem, because solution space analysis divides into multiple parts. I am identifying which RO types are needed in PMR. Hesham - The PAN is a very loose term, and trying to make it concrete is a slippery slope. These assumptions are almost product specific. Vijay D - We've had RO on the charter for a long time. It's simple to define - we need communication from one mobile net to another mobile net. But we need concrete use cases that describe exactly what we want to optimize. All three of these categories have different needs. Whatever we develop for two MRs on one personal area can be extended to any scenario. But our requirement is to provide a more concrete use case. To address Gabriel - how a PAN gets organized and how it attaches, or whether it's nested, has been out of scope for the entire NEMO wg. Basic support does not make any assumptions about this. Alex Petrescu - To address Hesham's question - Why would a mobile router be the phone, and not a camera or a laptop? But a camera usually only has one interface, not more than one. Typically the mobile phone has several interfaces, which makes it a good candidate for MR. Behcet S. - Question on 2nd bulled (Prefix allocated by ISP). Currently, you can't even get an address from an ISP. So how are you going to get a whole prefix? A: With IPv6, I think it won't be a problem. TJ: Not sure what Behcet means – RO could have a lot of implications for implementing MR on consumer devices such as the need to get prefixes Hesham - This can provide more reasons why RO is useful, which is nice but.. Or we can say there are certain scenarios that make it easier to implement RO..We need something more concrete. Gabriel - Another question along those lines - Nowadays, this would not happen. Your phone switches to Wi-Fi in your house, and all the other devices use this as well. So things today are a lot simpler. Why would we want to go to this type of more complicated scenario? We need to have a justification for that. A: The problem there is not when the devices are all at home. When they leave the home, we need to be able to have persistent addresses. That means different mobile network prefixes. (Discussion continues.. see Jabber logs) 4. Use Case Automotive ........................................... 15 mins Update of NEMO Route Optimization Requirements from the automitive industry Roberto Baldessari http://www.ietf.org/internet-drafts/draft-baldessari-c2ccc-nemo-req-01.txt Discussion: Hesham - To be clear, you're not saying some applications should be able to reject RO? A: Should be able to use bi-dir tunnel. Hesham - If it's already triggered, should the application say no and use a bi-dir tunnel? A: Yes. The application should be able to choose Requirement 2 - Can we have comments on this? Hesham - If the MR is a FW that decides not to allow IPsec, what can we do? Roberto: I'm talking about RO.. Might prevent MNs to work. It depends how the solution is designed. There haven't been RO proposals. Thierry - No, there was a lot of proposals. But many of them do not meet your requirements. Hesham - Where would RO stop this from happening? Jari Arkko - I think it is fairly obvious, and a message from your AD: If the WG tries to develop something that breaks IPv6 in MNNs, that would be bad and your documents won't be advanced. MNNs have to be able to do whatever they would do otherwise, or else it is a broken solution. Hesham - The first requirement seems to make it possible to break IPv6. Jari - I took the first requirement as an option, so that apps that want to have that option can affect what's done lower in the stack. TJ: RO is an optimization, if your implementation doesn't use it at some point then fine. Maybe not stated clearly. Hesham: undisputed is that, but clarifying that... of course not... if two apps and one wants to bypass the ro then, that's wording of the req. Roberto baldessari: alternative wording will propose on list Gabriel - I was going to say the same thing - an optimization is just that. There is such a thing as premature or harmful optimization. It must be able to be turned off without any effect. Will Ivancic - The aviation community has a similar requirement. It's really the ability to do some policy-based routing. So critical data can take a certain path, etc. Jari A. - Who is the one that gets to choose? Is it the router or a MNN? A: It's the router running in the vehicle. I.e. taking into consideration the speed of the vehicle. Jari - That's fine, and you should explicitly state that in the requirement. Suresh - It's not obvious to me whether this would work. But you could set a flag to do RO. In aviation industry, you may want to go through HA path. But what if the CN has a binding for you? You can't force it to happen on a per-application basis. Will - I don't think you'd want to do it on a per-application basis. But we want that requirement in, to see if we can fulfill it. You can handle these with a combination of NEMO and other engineering techniques. [Requirement 3, RO security] Gabriel - This seems more like a requirement for the internal project itself. It would only be a requirement for the IETF if the IETF needs a solution. But if you're using an external solution, you would add it to your project. A: What if I remove the part in the brackets? Jari A - I would agree that this is really in the solution space. The requirement at the top is clear to me, but the rest is handwaving. Stick to the statement at the top. Alex - I agree with Jari. Designing a secure RO technique is something we really want. J-M Combes - Prefix is owned by MR owner, or ISP that provided the prefix? A: Same as specified as in RFC 4225. [Summary] Thierry - How many people read the draft? About 10. Thierry - Question. This is expressing needs by C2CC. But there are other groups such as ISO. They might contribute to the IETF with somewhat different requirements. Hesham - Another question. Are we in the requirements collection phase to develop a single document? If we have 4 or 5 sets of requirements, we could have 20 solutions competing. Thierry - We have 3 different important use cases. We should have a separate document so people understand what the needs are. TJ: NEMO investigates requirements; the new charter is to id main use cases of industries that have deployment needs now. TJ: further, gather reqs into individual documents. TJ: to my mind, like starting with _one_ RO solution, not separate for use cases. TJ: to me makes sense try and merge the automotive in one document, ISO and CC Will Ivancic - I think it's good to have separate documents initially, but in the end I would want to have one consensus req document. Suresh - I agree with William as well. We need to find out if there are potentially conflicting requirements first, but we don't need one for each solutions requirement doc. Alex - Coming back from solution to requirements. So q was whether we want to see a common doc between ISO and C2CC. It's a good idea, but until now we've only seen a C2CC document. Thierry: time enough to wonder the c2c doc next or more discussion is needed on that? Who thinks the c2c req document should be a WG item? Jari - I think you should have a conditional acceptance based on the condition that other bodies involved in the car space would be merged in. But i'm against the idea of merging everything together. The reason current charter is written how it is, if you look at the space as a whole, the RO problem is huge, and we are not doing a research project. We need a specific solution for specific needs. Authors of this document need to take into account other views Will - Would each industry document go through to RFC or carry on a little longer till they're merged. Jari - I think we would take them through to RFC, but next we would have to take a look at solution space. 5. Aeronatuics and Space RO Requirements (1/2) .......................... 15 mins Summary of discussion and issues for the aeronautic use case William D. Ivancic http://www.ietf.org/internet-drafts/draft-eddy-nemo-aero-reqs-01.txt [Required Characteristics] Jari - Would you want to bypass the RO by router or by host? A: By router Hesham - These required characteristics.. (lost the end of the q) A: These are ICAO requirements, all really driven by safety of flight. Hesham - You might want to break things up by critical, important and desirable. A: Agreed. George T. - What are we going to do in protocol design to make sure throughput is high? Suresh - on last slide, this is the right way to look at things. Not from one or another industry, but if I have a crash, I want traffic to go through critical channel. Thierry - We have a consensus that we will split things up by industry - we will not go back on that. Wesley Eddy - I would answer throughput requirement question. It came from a shorter and less specific statement from ICAO, and in order to retain that input I left it in there. This requirement may be a no-op TJ: if this is a concern I'd like to see it restated a little bit in terms of bandwidth, signalling overhead, 9.2kbit link A: can go over on the list, very much on it and agree on it. George Tsirtsis: both scalability and throughput req should be restated that way. GT: difficult reqs to verify at the end that usefulneses, effor to make solution scalable and efficient. TJ: If there is more data from ICAO or another group, that can be added as footnote to the draft, so people can wrap their minds around the problem. A: certainly. Gabriel - I've been trying to wrap my head around the integrity requirement here. I thought this implied authentication code... but maybe it's more akin to no add'l packet loss. But that's a hard requirement because with RO you are using a different path, and RO has no choice about that path. It might be a poor path w.r.t. packet loss. So maybe you want to compare the paths so you can choose. A: The idea was that you don't end up on a route optimized path that has filtering or you can't get packets through. Gabriel - They might be requirements that can't be addressed in RO itself, but other WGs can help with requirements for choosing a path. A: Agreed. There are other engineering solutions for some of these things. Terry Davis - Part of what we're getting at - when we did Conexion by Boeing, we went to great efforts to avoid losing in-flight packets when transitioning from one ground station to another. Jari A. - I agree with most of the requirements. I wonder if this is specific enough. We need this to decide whether a soltuion meets your requirements. Also, you may be missing non-requirements, and things that are not issues for you. A: agreed. Hugh Mought? - representing Airbus / Aerospace Consulting Consortium (?). On adaptibility, something missing but I'm not sure we should write it down. Our products have 25-30 year life cycles. Will continuing to go through Required Characteristics. On first question - How many people think this document fits the charter and should become a WG doc? - About 20 for yes, and 0 for no. Consensus to make it a WG document. On second question, please comment at mic or on mailing list. 6. Aeronautic Use Case (2/2) ..................................... 15 mins Mobile IPv6 Route Optimisation for Network Mobility (MIRON): How this solution fits the Aeronautics requirements? Carlos J. Bernardos http://www.ietf.org/internet-drafts/draft-bernardos-nemo-miron-01.txt http://www.ietf.org/internet-drafts/draft-eddy-nemo-aero-reqs-01.txt This presentation shows a solution that has been there for 3 or 4 years, and see how it fits aeronautical requirements. Hesham - If you're using ESP, do you multiplex the traffic at the MR to figure out which MN it should go to based on the SPI? A: Packets from the CN will carry the routing header. 7. Elimination of Proxy NDP from Home Agent Operations .......... 15 mins Ryuji Wakikawa Informational document related to the home network models document. The document lists potential operational issues about the HA intercepting packets without proxy ND and gives tips. http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-no-ndp-01 -- This is expected to be the last NEMO meeting, as the working group's charter and work items will be merged with the new MEXT working group. We will continue these work items on the MEXT mailing list.