NETLMM WG 0900 Thursday Agenda bashing - all, 5 min. Draft status - James Kempf, 5 min. SDO Liason Update - James Kempf, 5 min. Ground Rules for Discussion - Jari Arkko, 5 min. Context for Current Situation - Phil Roberts, 5 min. Summary of Design Team Document - Henrik Levkowetz, 10 min. draft-sgundave-mipv6-proxymipv6-00 - Sri Gundaveli, 5 min. draft-chowdhury-netmip6-01 - Kuntal Chowdhury, 5 min. draft-templin-autoconf-netlmm-dhcp-04.txt - Fred Templin, 5 min. Discussion, all - 20 min. Consensus Call - James Kempf, 5 min Draft status 3 drafts with the IESG problem statement: all Discuss comments resolved Requirements: all discuss comments resolved threats: just got comments from security area, current state: IESG evaluation SDO Liaison update Conf call with 3gpp SAE chair Liaisons discussed on Tuesday S2 and S5 interfaces: inter-technology. They would like to use an IETF solution. They are looking at Network based Mobile iP, others GTP also Schedule: architecture by 06/07 protocols selected 12/07 Lunch meeting with 3GPP2 on Tuesday Thomas Narten, Jari Arkko, NETLMM co-chairs, AC Mahendran, a few others They submitted a liaison stating that they want Proxy Mobile IP Whether or not HA is changed. They want global MM, would settle for local. Wimax forum JAK presented NELMM DT protocol in August Reception was hostile Ground rules for discussion Jari Arkko We have had lots of discussion; solution might use any of the proposals. We do need to make a decision otherwise there will not be an IETF protocol. Community decision. We have had some requirements approved : we will not compromise on those requirements. We also will not be changing the link model. We don't want a link with multi-link subnet problems. Some proposals may need some changes. All standards-track requirements apply. There will be some changes to implementations no matter what protocol is chosen. There will be some work needed on all drafts. IETF has change control: if you have already deployed something, it may be different from what you have. In addition to protocol choice, there is also the question of how many protocols we want to have. Sometimes we do 1, sometimes we do several and let the market decide. Jari doesn't care which, would just like an informed decision to be made. Kent: on the requirements, agree there should not be compromise, however, there should be more clarification of the requirements. One example: SDO would like to use MIP based protocol, not clear whether they require no changes or some changes. Should clarify up-front. Jari: we have had a lot of discussion on re-use. You can't do this and satisfy the link model without some changes (personal technical opinion). Kent: agree but need to clarify James: Technical issue. It's not a requirement. Is it possible to engineer a protocol that can do this or not. Jari: requirements that will not be compromised are functional requirements. Re-use argument is one of the factors that we have to take into account. Context for current situation Phil Roberts How we got to where we are. DT worked all summer and produced a document. Call on the mailing list to see whether DT document should be WG document. We had very rought consensus, but wanted to see if we could get better consensus. Discussion did not have a good start. We had hoped to have a better technical discussion. One of the things that happened is that people who wanted DT document have changed their mind and now want Proxy MIP solution. Today: we want to get a sense of the room for what drafts should be WG drafts. Open discussion about all 4 proposals, then we will ask some questions about consensus for how to move forward. We will also revisit question as to whether we go forward with 2 proposals or 1. If you care, please stop reading your e-mail. Summary of Design Team Document Henrik Levkowetz 3 presentations: agenda changed This will be a mix Current version incorporates all comments since Montreal 7-8 pages of fixes Remaining Issues renaming a message and some other things not really serious. The DT Proposal: one page We have a topology where a MN wants to communicate with a CN using a plain, standard IP connection to both of them. Then, we have a network consisting of an anchor and a number of access routers that handle mobility on behalf of the MN. The DT document is a clean match between protocol and topology. Important, unique to the DT document in comparision with others, but people may have different ideas. The DT document uses identity-locator split so it runs over v4, v6, or mixed networks. There may be some details to running over v4 with NATs: it may work or it may need some polishing. Optimized handover performance: single round trip. Support for not only mobility handling but also for taking down and taking up individual ARs in a way that can be managed nicely. What now? Consequences of doing a different choice should be mentioned: Why NETLMM based on PMIP is a bad idea: there is a trust relationship mismatch between what is assumed for MIP and what we have in this case. The MIP protocol assume trust between MN and HA. It is implicit in the design of that protocol. Going with PMIP creates a new transport protocol: no port numbers, etc. Management mismatch: based on the fact that topology is different. Trust relationship mismatch MIP assumes one-to-one trust relationship between MN and HA In netlmm, the trust relationship is between the AR and the Anchor in PMIP, you have to fake the trust relationship. MN-AR trust relationship: NULL trust relationship: BUs don't have per-MN authentication. Lets anybody inject BUs ARs hold keys for all MNs, much data, in a vulnerable location May fetch keys from AAA server at time of handover. Can be solved, but not without pain. New transport protocol In MIP4 we used a regular transport protocol. In MIP6, there is a MH in the IP packet. Makes sense because you have IP layer in MN communicating with IP layer in HA. However, in netlmm, we don't have that. Instead we have underlaying network mobility management. Using PMIP means that the application-to-application messaging using MH. This is a mismatch. It may work, but sets a bad precedent. Management Mismatch. MIP has bootstrapping technologies: you can use them to bootstrap ARs or ARs view of the MN, but you can't do both. This can be handled but will bloat the MIPv6 more. JAK: please hold comments until discussion period Kent: one thing missing is sequencing that we have put in NETLMM which is different between. Sri Gundavelli Proxy Mobile IPv6 Goal: providing mobility to a host that is not required to participate in the mobility signaling. We posted the draft 1 year back when NETLMM DT was created. We revised it a few months back, wanted to provide a short-term solution. Assumptions: MN-AR is a p-to-p link. Access authorization ensures a secure MN-AR link. Per MN prefix model (do support per-MN address model, but requires extra messaging between AR and HA). New entity: Proxy Mobile Agent It is like a MIPv4 FA PMIP Model picture MN, AR with Proxy Mobile Agent (PMA) Prefix is topologically anchored at HA. With the localized network, MN gets mobility service without having to participate. Home prefix link is following the MN. Addressing models 2 models Per MN prefix model HA creates routing state for the MN just like NEMO. Address pool configuration in DHCP, can create a bunch of pools. When MN attaches and sends DHCP request, the AR can act as DHCP relay, DHCP can allocate an address from that block. Node requesting address is the MN, it always gets same address Per MN Address model We can do this but requires HA to be involved in ND related operations. HA needs to participate in global address/LLA uniqueness Address Allocation Schemes both stateless and stateful MN goes roaming, attaches to AR, gets RA, MN can pick an address, AR will do proxy registration for that. We are registering a prefix with the HA. DHCP based address config mode, AR acts as a relay. We have an implementation and were able to demo this. Home Agent Changes Proxy model requires a different trust relationship. The MN is not in the picture. The trust model is between the HA and AR. Changes: modify the logic about how we validate the BU. The HA has to check whether the BU is protected by an SA. In MIPv6 there is a one-to-one relationship between the MN and HA. In proxy MIP, there is one tunnel, multiple MNs. Handling the sequence numbers in the proxy BU needs to be modified, the Proxy sending the BU will not be able to set the sequence number correctly. draft-chowdhury-netmip6-01 Kuntal Draft wrote last year to describe the use of MIPv6 in the network, client doesn't have MIP6. Want to re-use the deployed HAs as much as possible. Solution overview: defines how MN can connect to the network using Proxy MIPv6, call flows showing DHCP and PPP/IPCP cases. Reuses base MIP6 base protocol for MM. No new MH and MO introduced. Supports both v4 and v6 addressing. Proxy MIP client sitting in the Access Router. Addresses inter-access router (AR) handoffs Inter AR signaling with ICMPv6 extensions Includes HMIP6 consideration Proxy HMIPv6 within the MAP footprint Network Localized Mobility Management using DHCP Fred Templin Picture of NETLMM domain ARs, backhaul network, MNs Support for 3 types of MNs: DHCP only SLAAC-only DHCP + SLAAC AR combines both DHCP client and relay. They are co-resident on the AR. The relay performs ordinary relaying, also controls IP routing table. Client is responsible for Model of operation MNs use DHCP and/or SLAAC and observe the MN-AR interface spec ARs/MAPs use ordinary DHCP message exchanges IP forwarding tables are managed Host-initiated HOs driven by MNs Network initiated HOs driven by ARs Host initiated message exchange Call flow picture DHCP request starts off Network initiated exchange: AR detects MN on link, DHCP Info-Request sent to MAP Motivation Deliver best solution to address customer requirements DT document has no visibility Proxy MIP was not on the radar screen Solution uses already deployed infrastructure Draft version 4: support for v4 and v6 DHCPv6 requires RAAN, SRSN options (in WGLC for PS) Discussion Please address the authors with questions about particular proposals Comments/questions? Hesham Regardless of the protocol that Henrik or Sri presented, we do need context transfer for either one to work. The AR doesn't know which LMA or HA to send it to. Is that correct? Henrik: AR to AR CT? No, you don't need that. In the DT draft it is clearly laid out. Hesham: in you proposal, how does nAR know where to send the message? Henrik: in authenticating the MN, the AAA infrastructure will deliver a message to the AR regarding which anchor to use. You have to know which anchor to use, it is not context transfer. Hesham: ok, not AR-to-AR, but you require the AAA infrastructure to know it. Kuntal: I have AR-to-AR communication in my draft. Inter-AR signaling within a trusted domain is possible; faster than AAA. Henrik: We did discuss doing CT, but decided to do basic thing first, add that later. Sri: In our approach, each AR goes off and downloads profile. Additional function that is not in the first draft. Hesham: so you need context transfer of some form, why not transfer SN as well. Sri: could do that. Fred: if we wanted to have some kind of HO between oAR and nAR we could have some way to tell the AR where the MAP is. Henrik: equivalent question is how, if you have multiple DHCP anchors, how does the relay know which one to use? Fred: you could have some protocol running in the background to synchronize multiple servers Henrik: so you would need to hard code it Fred: standard DHCP configurationp Hesham: unless there is some form of CT, there may be some race conditions. If we want to have acceptable window for a BU, need to handle the case where the MN is moving fast between ARs Henrik: we have that in the draft. Vijay: We should just do a simple protocol first, not worry about CT. Jari: would also like to have that. Do the simple thing now. Vijay: Comments on Henrik's presentation: made a bunch of statements I'll bring them up on the mailing list. JAK & Henrik: These were Henrik's opinions Jari: if there are significant issues, maybe we should bring the slides back up. mic: 2 questions: HA based entity that will manage the mobility will be also used for Micromobility? Phil: I think your question is can we isolate part of the ops to be network only and client based on the same HA. JAK: authors of PMIP drafts like to address that? Kuntal: the same HA can deal with both, the MIP6 operations are the same. Separate contexts for CMIP and PMIP, we didn't need that distinction. Sri: HA can support both. Henrik: same node can sometimes use PMIP, and sometimes use CMIP? Sri: no, from the HA pov, the client is just an IPv6 host, this is just for local mobility. Henrik: sounds like a no, correct answer. George Tsirtsis: people agree that same HA wants to handle CMIP and PMIP. We should want, as IETF, for the network to support both as well. We don't want to interfere. mic: Proxy MIP6 solution, there is an assumption of a p2p link. WHat is the status? JAK: we had a discussion in August about using prefix per MN. As Jari mentioned, we don't want to go back on that decision. Was not discussed as to whether that was p2p link or shared. AlexP: a little correction: what I heard AD say was that we want to have link model without multi-link subnet issues. Jari: that's the basic requirement, we already made decision about per-MN prefix. AlexP: if we look at PMIP, the AR tries to emulate MNs home prefix, logically, immediately one thinks there is a multilink subnet. Jari: If you do that there is an issue, some of the authors had MN getting its own prefix. Sri: Prefix is anchored at home link, AR will give the prefix to the MN. AhmadMuhanna: From Jari, there will be a consensus call, both drafts for Proxy MIP will be considered to handle local mobility signaling. Don't want two different drafts that are the same solution. Jari: the consensus call will be first whether we have multiple, then about the direction of the work. It's only a starting point, the WG has the full power to change the contents. AM: heard a comment from Vijay that we need a base protocol, we need to address the needs of the industry. Jari: symmpathetic to having addl requirements, let's get the base done first. AM: why do we have to pick one of them? Maybe we can combine both PMIP drafts? Jari: We need to pick A starting point, that's not the final result. If we try to do the merge right now there will be a mess. Vidya: Why are we discussing this now? Vidya: multi-link subnet requirements: we should be conscious of ml subnet issues. One thing that George mentioned was that we need to let CMIP clients co-exist with PMIP, netlmm. Not sure that prefix-per-MN can co-exist with client MIP. A regular IPv6 node that shows up and sends RS, does the node know that it is a unique prefix? Jari: starting point should be that netlmm network looks like a regular IPv6 network. Whether you can have one MN's prefix be able to do that, we need to work on that. Vidya: need co-existence Henrik: Agree fully with the requirement, whatever solution we pick we must make sure this is possible. Don't think we have to decide it now. Vidya: no, agreed. Another question: NEMO was raised as an analogy, this is not NEMO. Fred: prefix per MN vs. Shared prefix, I have not heard yet a problem with having a shared link. Haven't heard anything Sri: on vidya's comment: from HA pov, it is creating state just like NEMO Vidya: can be made to work from HA perspective, is a subset of NEMO, where router is on the home subnet. THere is a difference between this and NEMO. GeorgeT: Another thing that concerns me is the level of IPv4-related information in them. Any proposal that goes ahead should define the IPv4 operation from the beginning. Henrik: Would like a clarification: we have 2 places where this is important: IPv4/v6 user traffic vs. infrastructure. It would be best if we could handle both IPv4 and v6 in both cases. GeorgeT: It is necessary to support dual-stack MNs, having a protocol that can work over both v4 & v6 is not as necessary. Fred: first customers are IPv4 based, so we have that covered. Kuntal: if we can use the same mechanism to support v4. HenriK: user of infra? Kuntal: for the user. IF network is based on PMIPv6 protocol, should be able to support v4 mobiles. That's the way to go. Kent: Henrik raised a good point: should clarify this in the requirements. Vidya: Agree that we need to clarify; a lot of them are talking about IPv4 endpoints. Fred, talking about Fred: IPv4 infrastructure for IPv4 endpoints, IPv6 for IPv6 endpoints, but we could do it the other ways too. Vidya: so is you requirement for v4 endpoints or infra? Fred: could do both. Vidya: doesn't seem so important to support v4 infrastructure. It may be difficult to handle NATs later. JAK: Requirements are with the IESG so it hasn't changed. If solution does support it without any problem... Vidya: with v4 we have to assume NATs AlexP: Support doing IPv6 only now. Extending MIP6 to become Proxy MIP6: henrik's slide about bootstrapping: can bootstrap either MN or AR. I disagree: today bs only works for MN. JAK: why? AlexP: trust relationship. Henrik: Agree, but used different words. We can't use the same bs to handle both AR and MN SAs. AlexP: wanted to emphasize fact that PMIP trust model is different. Fred's choice of DHCP is a 4th choice. Description of protocol could be triggers for NETLMM protocol. That draft has a very strong case: interoperable implementations. Hesham: One key question: validity of PMIP: can you explain how you can support both CMIP and PMIP? Phil: question in general, or just...? Sri: Node is just a pure IPv6 host, we did not say it could do it. Kuntal: once MN connects to the network, it is just running application over IPv6 link. Whether same HA is used is another discussion, we could have one box doing 2 different functions. Once you run PMIP, MIPv6 would just be an application on top. Hesham: One of the key advantages of PMIP is that we could use PMIP and CMIP in the same network. GeorgeT: what he described is running one on top of the other, that's not what we are talking about. We want to talk about running them both at the same level. Kuntal: that becomes messy AM: same MN running both CMIP and PMIP? Hesham: no, another MN in the same network using CMIP AM: absolutely yes Phil: clarification Hesham: 2 MNs in same network, on using CMIP and one using PMIP AM: yes as long as PMIP session is known as a PMIP session. Sri: yes, HA should be able to handle both PMIP and CMIP clients. Hesham: hope so, want to know how. Sri: PMIP flag is one way. Either separate MH type or PMIP bit flag. Phil: One of the things that is apparent is that we haven't read all of these drafts. We want people to read drafts and that's why the consensus call will be on the ML. Hesham: don't think a bit is enough Sri: if we can distinguish using a bit PMIP and CMIP can be supported. Jari: let's now design on the fly here. It's more than a bit. Vidya: yes. In all the solutions, the AR needs to know whether it is acting as a proxy or whether the MN can handle its own mobility. AAA server might know. Another possible model is an overlay model. MIP CoA is actually the LMM address. A flag is not going to solve this. Phil: combination of architecture and policy, don't need protocol support Vidya: yes Kent: question: do we support CMIP over PMIP, and also run independently CMIP and PMIP? JAK: requirement that it has to support all client-based mobility solutions. Kent: it is a matter of interpretation. Do we want to go through and check? JAK: We don't need to check on MIP, HIP, etc. Fred: it's situational whether MN initiates the handover or the network does AM: what Jari said: we are not here to find a solution, but to understand the requirements. Any solution should support both CMIP and PMIP. JAK: any additional comments? Jari: go back to Henrik's slides? JAK: Ok, this is a consensus call. Sometimes people get confused. First call: which approach to adopt. Not talking about a specific draft, just the approach. Q #1: Should the NETLMM WG adopt the DT draft? Q #2: Should the NETLMM WG adopt ONE PMIP draft? Q #3: Should the NETLMM WG adopt a DHCP-based approach? Q #4: Should the NETLMM WG adopt more than one draft/approach? Last question first: Q #4: About 10 people in favor: Overwhelming support against. We will adopt only one approach. 3 approaches on the table: 1st is DHCP approach. Alex: don't agree with the question, we could merge DHCP draft into the DT draft. Jari: we have to pick a starting point. Fred: can we vote for multiple drafts? JAK: you can vote as many times as you want. DHCP based approach?: 3 hands Should the NETLMM WG adopt a PMIP draft? 45 hands plus a couple on jabber Should NETLMM adopt DT draft? 30 hands. Jari: we have to go to the ML, it is a bit too close to make a decision. Hopefully we will get some additional feedback. AlexP: There might be 2 similar approaches, one gets standards track the other doesn't. Can we do that? Jari: Also a possibility, we talked about if the WG wants to do 1 approach, we could publish an Informational on another one. AM: Counts? Phil: 45 on PMIP, 30 on DT, 3 on DHCP. GeorgeT: IETF should only do 1. Cannot stop anybody from publishing an informational RFC. Kent: picking one draft as standards track: do we need to see consensus from the group having one as informational or experimental? Jari: we could ask about that, given the results, whether we should reverse the decision of whether we want one. Change to standards track vs. experimental JAK: 3GPP2 requires standards track Thomas: not true Vijay: There was consensus to do just 1 solution both in MIP6 and NETLMM. Why are we discussin again? Jari: We're at a situation where we need 1 solution that is good for the industry, but we have 2 camps. AM: didn't understand the communication from 3GPP2. Understanding that the result is clear JAK: Thomas can you clarify Thomas: 3GPP2 sent a liaison statement saying they want PMIP based approach. They didn't say anything about standards track vs. informational/experimental. Remember auth option. AM: Yes, we need standards track Avi Lior: 3GPP2, in order to publish a document, all we need is an RFC number. Kent: Given the 3GPP2 statement, does that constitute a requirements change to this group. Is it or is it not a requirement? Thomas: No, it is input to the IETF. We could tell them to go away. AlexP: it is something we have been told. It is good to know, but we can make a statement in response. Vidya: Jari made it perfectly clear: IETF has change control and this is non-neogotiable. One q: Q#4 one draft? Hope it applied to any standards-track or non-standards track documents. Thomas: Sense of the room is a little contradictory. There seems to be consensus for having one blessed approach in the IETF. However, 45-to-30 is pretty rough especially on fundamental question of the approach. The question is does the IETF want to focus on 2 separate approaches. Traditionally we want to limit that if possible. Hesham: Agree with Thomas, but no one can dictate to IETF what the solution will be, if we go DT draft, PMIP can go informational or the other way around. JAK: it certainly would have been nice to get input earlier. AM: it is clear that everyone wants one solution. Phil: Consensus is still rough. We need to have more discussion. Jari: one interpretation of the 1st question is that everyone is willing to sacrifice their own solution. We did get a majority of hands for one solution, maybe that tells us something. Henrik: Possibly knowing the answer to the 1st 3 questions, it might be appropriate to ask the 4th question again. AM: how many times do we need to get consensus? We can go to the list, but the consensus was that we need one solution. mic: First two approaches ; if we adopt the second one only, we are stuck with deficiencies, cost of local mobility Should we look at the last question again, debate whether there is need for Margaret: suggestion: there were an awful lot of people who want one solution, then went through 3 choices. There is no way to weigh that against their preferences. PMIP draft got more votes; I think we should pick one. Is there a way to ask the group whether the majority vote should carry the day? Hesham: last question was saying that, we all voted yes for one solution. Personally I voted for PMIP but I don't care. If others are so rigid in their opinions, there is the alternative of 2 experimentals. Then come back in a year and find out which one got deployed. Avi: Industry needs are getting lost here. 3GPP2 and Wimax are going for PMIP. Who are the other customers? JAK: also 3GPP. Fred: my customers don't have MIP, they do have DHCP. Whether it becomes an experimental draft I'm not that religious on but I need to satisfy my customers. Margaret: Maybe we should ask whether we want to go with PMIP solution exclusively. JAK: How many people would be comfortable going with PMIP exclusively. For: 50 Against: 23 Jari: that is close enough. This is the direction we should go; we'll confirm on the mailing list. We have some further questions. Jak: Which PMIP draft should the WG adopt? Avi: question: is it possible to take concepts from each of these drafts and merge them. JAK: This is just a starting point, always open to WG input. Gerardo: If a doc is adopted as a WG item, you can always take input from another doc. JAK: draft-sgundave-mipv6-proxymipv6-00: About 18 draft-chowdhury-netmip6-01 About 7 Who thinks we shouldn't decide now? About 28. Most people want to wait. We will confirm all these calls on the list. GeorgeT: it is easier to add things than to take them away, so the smaller draft has an advantage. Vijay: authors should get together an harmonize the approaches JAK: that would be great. Jari: Looking at some of the proposals, there are some bad things in some of them, so don't go too far. JAK: that's it, we will confirm on the list.