** DRAFT MINUTES ** DMM at IETF#84 Vancouver, CA. Tuesday July 31, 2012 0900 ** Agenda: Lots of docs have been submitted, but we're going to focus on WG milestones. ** Requirements Discussion: We will go over it, have a chance to express opinions, we will take issues to ML, and last call the document. Let's not spend too much time on it. ** Best Practices & Gap Analysis: 2 documents, 20 minutes each Discussion, then we will decide what to do with these documents. ** WG Status Update: o Documents in WG Process: - draft-ietf-dmm-requirements, we are a bit ahead of schedule. Will look for WGLC after this meeting. o After best practices & gap analysis discussion, we may select one of these documents as a basis for WG or merge them or decide we need a third one. Need to expedite progress on these so we can move into solution space. ** Milestones: o List, first one already done (the adoption of the requirements document). o Best practice & Gap analysis due in August. May be one or two documents. ** Anthony Chan and the Requirements discussion: o Long list of contributors.. o Format of document: requirements concise, only 6 requirements. Each has an explanation and background of what we want to solve. o REQ1: Distributed Deployment - PS1-4 (Problem Statements) o REQ2: Transparency to upper layers only when needed - PS5, O-PS1: wasting resources o REQ3: IPv6 deployment o REQ4: Compatibility - Should be compatible with existing solutions, also can be used in neighboring deployments if they have security between them o REQ5: Existing mobility protocols o REQ6: Security Considerations o Stating from REQ1: Tricci So: first requirement is not very clear. Focused on traffic or also signaling (control plane)? Do we need a clarification in this requirement to ensure that the signaling is also distributed? Anthony: open to interpretation. Traffic now refers to user plane. Any reason want to include signaling (control plane)? Tricci: just want to know when you say distributed whether you consider just traffic or also control plane Anthony: different people's publications, some of them are fully distributed, others just data plane and not control plane. Do not know which is better. If we leave it open we are more flexible. Ok if others want more specifics. Tricci: goal of the requirement is focused on bearer plane not the control plane. Anthony: distributed doesn't say what is distributed. Goal is that the traffic is optimized. Konstantinos Pentikousis (Kostas): not sure if this is copied verbatim from text, but my understanding is that the mobility management is distributed. Tricci: key thing is that the traffic Kostas: core part of the requirement is the distributed mobility management. Whether traffic goes to core or not doesn't mean it isn't optimal. Anthony: you may not want to call Mobile IP a centralized protocol, it is really the deployment that makes it centralized. Not talking about the protocol. Yuri Ismailov (Yuri): DMM must enable distributed so that traffic may traverse nearest anchor instead of a centrally deployed Kostas: no, this would imply a solution. The previous comment was where does MUST bind. Does it bind mobility management or optimal routing. Yuri: eliminate the word optimal from the requirement Sri Gundavelli (Sri): "without impacting subscriber controlled services" then it's ok. Kostas: "subscriber" refers to business. You can have a deployment in a campus which has DMM and no concept of a subscriber. Sri: mobility service is not business. It is integral to mobility service. Kostas: I would be alarmed if we had some sort of subscriber talk. Anthony: conclusion? Sri: if we remove the anchor point, put a local anchor point, have to say without impacting subscriber controlled services. Tricci: why remove the anchor? This is DMM why remove the anchor? Sri: if we remove the word anchor, then have to say subscriber services Scott Jennings: centralized solution in the control plane, distributed in the user plane, will this requirement be satisfied or not? Anthony: will be satisfied if you avoid the routing even if the control plane is centralized. Jouni: goes back to original comment where distribution means both, we should work it out. Anthony: didn't say anything other than "distributed deployment". If you distribute the data plane you're fine. Danny Moses (Danny): remove the last part of the sentence, just say "so that traffic can be routed in an optimal manner". When talking about centralized anchor implies a solution. Anthony: "without traversing" is comparing with existing solutions Danny: doesn't "optimal manner" say that? Anthony: so you're saying last part doesn't say anything new, just makes it more clear so that you don't have to do it in an existing manner. It is clarification, not a new requirement Dapeng Liu: if we remove the last sentence, we can't tell what is distributed Anthony: just make it more clear. Looks like we don't have different opinions just refinements. o REQ1 problem statement: These problems were raised by people before. Kostas: what is "Evolved Network Architecture"? Anthony: pointing to the more flattened network Kostas: need a reference? Anthony: ..? Jerry: 3GPP SAE when you say evolved network? Anthony: any network, including 3GPP Kostas: as an acronym/term, I haven't seen it. It alludes to 3GPP but that's not the terminology. Need to say specifically what this means. What is ENA? Is it Mobile IP? Is it 3GPP? Anthony: non-optimality as network architecture evolves? Jouni: we can find a new name for this. There should be plenty to choose from. Tricci: suggest remove the first part. Second part says what you want to say. Anthony: just a title sentence Jouni: next requirement? Anthony: take PS discussion to the mailing list? o REQ2: transparency only when needed: Any comments? Juan Carlos Zuniga: second sentence: "Such transparency..." is the transparency at the mobile node? Sri: what does IP layer mean here? It is too ambiguous. Mobility for a prefix or network could be stated in much simpler terms. Do not agree with this statement. Tricci: definitely is required to be transparent to the network, also desirable to be transparent to mobile host, do not necessarily need to mandate on the host, transparent to the network is the ultimate goal. Way it's written now is fine. Sri: what is IP layer there? What does that mean? Tricci: services/application Sri: single node? Network? Rest of statement talks about mobile networks Tricci: why does first part refer to only a single host? Anthony: second sentence tries to explain the first sentence Sri: what is transparency? Marco Liebsch (Marco): reflects requirement for IP address continuity. This provides transparency to the upper layers. Some applications may not require this. Anthony: requirement is trying to say how it relates to network mobility. Some one whose name we missed: Address continuity is the second part, session continuity is the first part. Anthony: session continuity is more specific, but how does that relate to network mobility? Tricci: don't want to impose any changes to the applications. Applications could change to deal with session continuity, but that's not what we want. On the mobile side it is desirable, network side it is required. Mobility transparency is probably a good clarification. Don't think session continuity is a good clarification. Alex Petrescu (Alex): echo comment by Sri: first phrase is something about HoA/CoA, session continuity, this is valid for mobile hosts, why mention mobile networks? Mobile networks could apply to all the requirements, not only here. Could also say that in mobile networks, a mobile router manages mobility transparently for LFNs (leaf networks). Anthony: want to call is "mobility transparency" Alex: just transparency is fine. Move the mobile hosts or mobile networks somewhere else. Jouni: so maybe we need to say in the introduction that all these requirements apply to both mobile hosts and mobile networks Anthony: second sentence is the situation, application is still transparent. So move second sentence to motivation? Alex: not the entire sentence Behcet Sarikaya (Behcet): send changes to the list, or to you, then you can make editorial changes Alex: can write e-mail on the list. Behcet: mobile network is one extension, multiple interfaces is another extension, these requirements are saying we should change the base. When we change the base, that's going to lead to a lot of changes and will impact all the extensions we have made. We will need to look at all of them. Anthony: there are many extensions, but there are only two things that can move. We are not talking about extensions. Juan Carlos: we agreed transparency should be for both mobile node and network, but this requirement refers only to the mobile host. Sentiment is that application should see transparency when needed. Don't like a statement somewhere else that says transparency is for both host and network. Anthony: need to do some work later. Tricci: PS5, mobility context is still very unclear. Some information like security context and location information is not only mobility context. Anthony: part of the context Tricci: not necessarily applies only to a mobility context. Last sentence of PS5 says network resources are wasted when mobility context is set up. Anthony: mobile host has a number of different contexts, mobility, security, etc., some of them are common. Tricci: so those are not wasted Anthony: right Tricci: just say "network resources" don't say mobility context. Anthony: definition of mobility context does not include security context and so on. That is not called the mobility context. Jouni: mobility context means tunnel state? Anthony: set up the tunnel Tricci: you have a definition in the draft that seems to imply security, location etc is part of the mobility context. Dapeng Liu: last sentence is confusing: "sometimes the entire application session runs while the terminal does not change the point of attachment". Seems to imply that sometimes the session runs while the terminal does change point of attachment. Anthony: means whole session is finished before any mobility. Kostas: sentence is fine. My understanding of mobility context is the mobility binding. I don't think security is included. Jouni: comes from definition. Tricci: that's not the definition of mobility context now. Fix the definition or drop the last part. Kostas: a term for mobility context is necessary. If it is ill-defined, we can fix it. The term mobility context is needed. The key idea is selective mobility support. Tricci: not sure I understand what mobility context means. IMO, network resources is not just the context itself. It is also the signaling. Just say network resources are wasted, full stop. Charlie: we had a mobility context when we did FMIP, it's not as if everything in there is useless outside of mobility, it is all the things you need to move when you do a handover. The point anyway is to get better performance. Jouni: we will go on the mailing list, make sure everybody understands what mobility context means, whether it stays in the document, whether it's ok to modify PS5 to remove it. o REQ3: IPv6 Deployment Straightforward? o REQ4: Compatibility two parts. Second part is compatibility with existing requirements so that existing solutions don't break, first is working between two domains that have security measures deployed. Tricci: req 4 is only specific for inter-domain? How about intra-domain? Anthony: only first part is on security. Second part is about running, doesn't mean inter-domain. Maybe we should reverse the order. Tricci: would be great. Kostas: make it 4.1, 4.2. Then not confusing. o REQ5: Existing mobility protocols Try to reuse and extend as much as possible before consider new development. Scott Jennings: you mean existing, IETF standards? Anthony: yes, want to include only IETF or also GTP? Decision: change to "reusing and extending the IETF standardized mobility protocols..." Juan Carlos: say "reusing OR extending" Jouni: from chair: this requirement is quite strict. We know the history of success of IETF protocols in commercial deployments. Coming up with a new protocol may not be a good idea. Some on whose name we missed: doesn't say MUST, not that strict Jouni: reality check Marco: it's true we have an agreement, but can we use other protocols throughout the framework, not just mobility protocols? Anthony: remove "mobility" Alex: "mobility-related". DHCP is a protocol that relates to mobility. Need to have an idea of what protocols we want or the group wants. Jouni: if these are working extensions on routing, for example, then we may find out we are in some other area. Then they need to get recruited to do those extensions because we are not experts on that. That is the kind of guidance about the boundaries. We have expertise on mobility protocols. Alex: reuse of protocols not restricted to mobility, but our expertise is mobility, what is the result here? Jouni: coming up with entirely new mobility protocol, doing something from scratch, is doomed to fail. If we start redefining some routing protocol, then someone will at some point of time will not like it. Small extensions make sense, then re-routing that extension to the routing WG, that has been done. It's basically the amount of changes/extensions that you do. Fei Song: re-use of extend current protocol makes sense, motivation is just another way to restate the content. Can change the motivation a little bit to make it worth something. Jouni: maybe the motivation would be "easier deployment by incremental update" Kostas: if the mobility protocols were not successful, why would re-using or extending them be successful? If XMPP or SIP DMM solution were proposed, would that be preferred? Jouni: There was a comment that it say "mobility-related" protocol. Anthony: ok, better to remove it. o REQ6: security Two parts Scott Jennings: e2e security, we can think of many ways to implement security with integrity/confidentiality? Do we need confidentiality, or is it just integrity? Sri: can we define what is DMM service here? Is DMM another type of service? Anthony: ok, don't need the new name Pete McCann (PeteM): service expectations are different because IP address may change Sri: transparency is a requirement PeteM: but only when needed Sri: will host know that I am in a DMM network vs. traditional? Kostas: there will be some entity in the host that will deal with the network. Anthony: change the wording, call it service or something else. Will take it to e-mail. Luc: REQ4: what do you mean by "trusted administrative domains"? Anthony: was talking about two different operators and how they work together Tricci: in 3GPP, refers to a relationship between two operators Luc: "trusted" is 3GPP definition? Tricci: just an example, not necessarily imposed on IETF Luc: need to define what is trusted vs. untrusted domains Anthony: so need a definition or change the word? Luc: yes. We will do a definition offline Jouni: time is out for this one. Tricci: Section 3.2 of the draft, what is the intent? There is a whole list of references. Do we need all those references in the draft? This is a requirements draft, those papers are solutions. What is the purpose of those references and the discussion? Anthony: explain what is distributed mobility. Only used published papers. If you don't want it, that's fine. Tricci: confusing because this is a requirements doc, those are solution architectures. Anthony: just background on what Distributed Mobility is. Tricci: maybe we can talk offline. Fei Song: security is an important part for DMM, need to say something specific Jouni: moving on. Anthony, you know what to do? At least you got feedback. Let's try to revise quickly after the meeting so that it is fresh in mind. Second part: gap analysis and best current practices. Anthony is already here. ** Anthony Chan - draft-chan-dmm-framework-gapanalysis o Tried to use a simplified framework to incorporate as much as possible - Abstract the functions of Mobile IP family - Basic logical functions - Mobility Routing (MR) - Home Address Allocation - Location Management (LM) - One (or more) Proxy may exist between LM and MN. - Gives rise to a unified framework, this will tell us where the gaps are. - Go through requirements: REQ5: consider existing protocols first, this is what we are doing o REQ4: compatibility, existing protocols are all considered - No fundamental difference between network-based vs. host-based protocol, treat MN as MAG+MN - For Mobile IP: * LM, MR, and HoA allocation in home network only host-based MN - For PMIP: * AR has its own IP address need an additional trust relationship between MN and AR * Host based and network-based can be compared together. - For HMIP: * In visited network, you have another MR. Put a hierarchy of information. - For multiple home networks: * LM, MR, and HoA allocation in each network * Trust to the other network, you can have network based mobility - For HAHA: * Have all the LMs talk to each other - Can you avoid the non-optimum route? * Use the IP address of whatever network you are using now. draft-liu-dmm-dynamic-anchor-discussion draft-bernardos-dmm-pmip draft-sarikaya-dmm-dmipv6 - What is the gap? Need to treat the HoA as belonging to the application, not the mobile host. Sri: multiple HoA, if you look at a MAG that can peer with multiple LMAs, can send RAs to MNs, in theory the MN is associated with multiple home addresses. Anthony: right. When you need session continuity and route optimization, enable them to signal to each other. LM is a distributed database, MRs can query any of them. Jouni: would benefit if the document had a clearly specified set of gaps. ** Juan-Carlos Zuniga DMM Gap Analysis o Trying to address the milestones from the charter, look at existing practices and compare against requirements. Because requirements are still being finalized, focus on structure of the document, make sure existing practices are the ones we should be looking at, then identify what is missing (but not spend too much time on that because requirements are still being finalized) o Existing solutions in DMM environment: - Client-based * MIPv6 / NEMO * MIPv6 RO * HMIPv6 * HA switch * Flow mobility * Source Address Selection API Behcet: what do you mean by SAS API? Which document? Juan Carlos: we have a reference Behcet: done in 6man, is not a mobility protocol Carlos: 5014 and 3484. API is documented. Behcet: were developed in IPv6 related groups like 6man. Why do we need to consider that here? Juan Carlos: these are existing solutions in IETF, want to see how they respond to our requirements Alex: FMIP, context transfer? Juan Carlos: ok Kostas: is this supposed to be an exhaustive list? Selective? Assumption is that all of these are based on RFCs. IETF standardized requirement discussed earlier. Probably 100 different solutions. Juan Carlos: tradeoff of course. Kostas: HIP is missing. Carlos: HIP and SIP are not IP mobility protocols. Charter says look at IP mobility protocols Juan Carlos: we are responding to the charter. Need to make a fair assessment of existing solutions. Jordan Melzer (Jordan): what about mobility protocols not invented in IETF? 3GPP standards? Juan Carlos: think it makes sense, GTP/SIPTO/LIPA is mentioned. If there is other stuff Marco: on HIP, you said it is not a mobility protocol, HIT is used as identifier, do we want to include LISP or LISP-like protocols? SHIM6? Charles Perkins: if you want to consider SIP mobility, provide text for the draft. Or DNS, or Socket, or HIP. We can allow that to be part of the draft, doesn't have to be author's responsibility. About 3GPP, is it really being proposed that IETF should consider GTP-C for DMM? I would be astounded. Sri: distinction is MM provided by applications rather than infrastructure. I do not think the charter allows application-type mobility. Juan Carlos: we can use that to cut down the list Sri: right, apps can have their own mechanisms - Network-based * Proxy Mobile IPv6 * Local routing * LMA runtime assignment * Source Address Selection * Multihoming in PMIPv6 (as per RFC 5213) o Will take all the previously listed examples, map them to each of the requirements we just discussed. This is work-in-progress, don't want to spend too much time because requirements are still being finalized. o Next steps - Provide more details for each existing solution - Include a summary of the gap analysis - Any other alternative protocol that should be analyzed? We heard a few, please let us know more. Dapeng Liu: is there any conclusion? Juan Carlos: right now no. Just an attempt to address milestones from charter, after WG adoption and discussion we can reach conclusion. Dapeng Liu: we should also consider other alternative protocols like HIP and other things that people might suggest. Some things might be out of scope. Juan Carlos: app mobility is different should be put aside, but to do a good job we should take a good look at what's out there. Jouni: Next Steps o Couple of questions - Would be ok to just combine these two as one document? Charles: having seen both presentations, seems like neither are ready. Anthony's is top-down, Juan Carlos' is bottom-up. There's not a natural merge algorithm. Maybe not all the possibilities are in the documents. Maybe they need to grow a bit individually before they are put together. Jouni: ok, so do we want two different documents, one on best practices another on gap analysis Tricci: is "best practices" for DMM or existing mobility management? Wait until we complete the gap analysis before we do best practices? Jouni: "Current" practices. There was an argument that we can do DMM with existing practices. Sri: another issue: coloring draft. Thought there was consensus to move that forward. Jouni: now entering solution space... Sri: work has other applications as well. Request AD to take that on a faster track. Don't want to wait on this entire thing to bake. Jouni: let's have a few more rounds as individual drafts. Requirements need to be stable. Then we can converge on one document. We are not going to accept either doc as a WG document after this IETF week. Hope that authors can make the next revisions quickly so that we can meet the August timeframe for adoption of the gap analysis. Jouni: on prefix coloring, topic fits in this group, also touches areas like 6man. Related work in dhc, already been aligned with the dmm draft. How many have read the prefix coloring document? -> One ;) Done, ahead of schedule.