FRIDAY, November 8, 2013; DMM WG IETF 88: 120 min 0900-1100 Morning Session I Georgia A ************************************************************************ Jouni Korhonen (JK, Chair) introduces and welcomes the new co-chair, Depeng Liu. - Agenda and WG update Note well presented. Anthony Chan (AC) and Carlos J. Bernardos (CJB) are the minute takers for the meeting. JK revises the agenda. The agenda is bashed. JK reports status of the WG documents. There are still things to be done, but they are moving forward. - draft-ietf-dmm-requirements AC presents the slides: http://www.ietf.org/proceedings/88/slides/slides-88-dmm-3.pptx AC: all the tickets after Berlin have been closed. Additional comments were received, which have also been resolved. Last minute comments from Sri Gundavelli (SG) also addressed. SG: I've just quickly gone through the document. Editorial changes are also needed. I'll read the document it and send these comments. AC asks when the comments will be sent. SG: One week. By next weekend. - draft-ietf-dmm-best-practices-gap-analysis Juan Carlos Zúñiga (JCZ) presents the slides: http://www.ietf.org/proceedings/88/slides/slides-88-dmm-4.pdf JCZ: a new version has been generated. Comments received on the ML. All comments since IETF87 have been addressed. The slides contain all the issues and how them have been addressed. For the time sake, JCZ directly goes to the conclusions. The Section 5 (GAP analysis) have been reworked. JCZ presents a summary of the main gaps: anchor selection, IP address management on the MN. The next step is to generate a new version, correcting some editorial issues. Alper Yegin (AY): changing anchor during a session will break the session, unless you have some solution in mind. JCZ: it's a gap, this is reported on the document. AY: I don't know how you can do change the anchor without breaking the session. JCZ: examples of how to do that were shown, for example, in some of the demos during IETF87. AY: the current text suggests IP session continuity despite anchor change, though there were two different sessions. SG: one way to do it is by injecting some BGP routes. AY: yes you can do that, then we need to fix them something on the terminology. Danny Moses (DM): why don't you say "initial anchor"? it's more correct. Suggests removing "optimal anchor". Georgios Karagiannis (GK): another issue is traffic steering. Traffic to the old anchor has to be redirected. The other point is where do we start to redirect the traffic and for how long we do it. JCZ: clarification question, steering traffic without mobility? GK: no, with mobility. Dapeng Liu (DL) wants to clarify the change of anchor. AY: I have to check the draft. JK (Chair) asks if people disagree that there is a gap with current specs regarding anchor selection. Alex Petrescu (AP) as Jabber Scribe: question from Jabber. Pete McCann (PC) asks a question about definition of which is an anchor. Anchor relocation with BGP updates is not anchor reallocation. JK: an anchor is the HA or LMA that terminates the tunnel for the IP address that you use to keep your sessions and provide global reachability. PC (via AP): this is your definition of anchor, but this definition assumes that you are using tunnels. JK: this definition assumes that we are using IP mobility. We ruled out working on application or transport layer mobility solutions. SG: in NETEXT we are working on CP/DP separation solutions. One one card you are running data plane, one another control plane. Data plane and control plane can be separated from a protocol point of view. One IP address is registered for control plane and another for data plane. JCZ: this gap analysis is for current practices. We restrict the gaps to the existing functionality. We identified a few gaps and we don't think that current solutions address all the gaps identified. JK (Chair): one a new revision is out, the issue tracker will be used. If people have comments, please move quick, I don't want to wait for London. AY: can we say a deadline for this? JCZ: new revision by Christmas. JK: once you have new version send an e-mail to chairs asking for WGLC. DL: gap analysis should justify the recharter discussion. - draft-yegin-dmm-ondemand-mobility-00 AY presents the slides: http://www.ietf.org/proceedings/88/slides/slides-88-dmm-5.pdf AY: this document was meant to be presented in the last IETF meeting. Not all the applications need persistent IP address. Different type of IP addresses, to be assigned to applications on demand. AY: RFC5014 defines API for applications to influence IP source address selection. HoA vs CoA distinction is not sufficient to reflect all the different types of addresses identified in the document. Besides, a normal MN does not need to use a HoA, as it runs client applications. New flags to ask for the new types of IP addresses in RFC5014. If the requested type of IP address is not available, the stack should try to configure one on demand. Policy: Configure type of IP addresses on host at boot time; Permission to grant which types of addresses. SG: (on the table slide) what is the definition of the access network? AY: the network the MN attaches to. SG: trying to see the assumption of this new definition. So far we have only CoA and HoA. AY: access network anchored address: the point is that the MN can move using that address because it is anchored, and the point is that it can be released at some point in time, as opposed to the centralized HoA. Charlie Perkins (CP): I support this, it actually removes the need for the presentation later on draft-liu-dmm-mobility-api. It opens an opportunity of working together. AY: indeed. DL: per flow binding on the type of IP address or per address? AY: per flow. Each flow may indicate different treatment. Marco Liebsch (ML): home network anchored is HoA, unanchored address is CoA. For the new one (access network anchored address), I'm not sure if the application is in place of deciding it. AY: refers to the whole decision logic explained on the table (slide 4). Ryuji Wakikawa (RW): you probably need to some work on the table on the definitions. From an application point of view, what is the benefit of having an access network anchored address? AY: less latency. RW: but you need to configure it. AY: right, if not already configured. JCZ: in the MIF architecture DT, characteristics like this have been brought up. This might be good to be shown also in MIF. - draft-liebsch-dmm-framework-analysis-0x ML presents the slides: http://www.ietf.org/proceedings/88/slides/slides-88-dmm-0.pptx ML: The methodology of the document is to specify 4 protocol agnostic functional elements. It can be used to build missing capabilities (gaps). DL (Chair): do you have any solution in mind? all the potential solutions fit in this framework? ML: yes, we have an appendix showing this. - draft-chan-dmm-framework-01 AC presents the slides: http://www.ietf.org/proceedings/88/slides/slides-88-dmm-1.pptx DL (Chair): why does the WG need this document? AC: framework and architecture are useful. KP (as co-author): 2 groups of authors are interested in working on it. We need something on a higher level to work on solution space. Tendency on IETF to work on particular solutions and we miss a bit the point from a higher point of view. It is not a question: we need a framework, we need a tool to allow us to work faster. Time to adopt this, as soon as the requirements and gaps documents are done. - draft-xiong-dmm-ip-reachability-00 Chunshan Xiong (CX) presents the slides: http://www.ietf.org/proceedings/88/slides/slides-88-dmm-6.pptx DL (chair): can you give us an scenario in which IP reachability is useful? CX: IP reachability related to routing aggregation issues. - draft-wakikawa-req-mobile-cp-separation RW presents the slides: http://www.ietf.org/proceedings/88/slides/slides-88-dmm-7.pptx RW: All components needed already IETF components. Idea to publish this as informational or experimental. AY: need some performance metrics. How fast is this? load involved, etc. Yo should also take into consideration the MN roaming to a network in a different BGP cloud (different operator). Brian Haberman (BH): clarification question, BGP within single AS? RW: yes, only within single AS. BH: thank you, thank you, thank you :) DL: clarification question on the "stateless" name. JK: do you have the required extensions on some draft? RW: yes. AY: there is state generated. ML: interested on seeing how BGP scales. JK: what else do you need in addition to the BGP extensions? RW: some guidelines on the whole thing. John: question on the stateless. How do you do the charging for example? RW: this may introduce extra state. CJB ask to be allowed to shortly present his slides as a deference for being a minute taker. Chairs agree. - Open Source DMM platform initiative CJB presents the slides: http://www.ietf.org/proceedings/88/slides/slides-88-dmm-2.pdf CJB: Demo was given in Berlin meeting. The open source code in C will be released in late 2013. Client-based DMM implementation to be added in 2014. Will be announced in DMM ML. - Milestones & Rechartering discussion JK (Chair): either we identify new work to be done or we close the WG. 30 minutes of open mic. KP: it will be catastrophic to close the WG. This is the future oriented WG on mobility, with all my respect to other mobility WGs. We could have done things a little bit faster. There is going to be a lot of European projects coming with H2020 providing tons of material. We have been having corridor discussions, the SDN thing is going to take off. There are a lot of people with good ideas that need a home. I think we should try to do a bit more than point to extensions. CP: Agree with what KP said. IETF is on a privileged position to work on protocols that work on EPC and WiFi. Enlarge charter to allow work on solutions that get adopted by 3GPP. JCZ: also agrees. Work done is good on requirements and gaps. Also thinks we should not restrict to do work on limited extensions, but also allows for more innovative solutions. For example, next week there is a going to be an SDN tutorial on IEEE 802 meeting. We haven't heard anybody against yet. We should keep these other initiatives in mind. BH (AD): many of the protocols developed haven't got as much traction as we thought, that does not mean it will get. Hat on: if you have a proposal of new work to be done, please come with a charter and let me see it. First finish current deliverables done and then we can have discussion on new things to do. Get involved in the IEEE 802 efforts, they are going to bring problems that are related to what we are doing at IETF. CP: IEEE 802 is too big, do you have anything specific in mind. BH: OmniRAN effort. SG: we have quite a lot of discussion, even we had a F2F meeting on wed. (slide presented). Aggregating control plane, distributing data plane is the trend. If we agree on that, there a set of extensions required (a list is presented on the slides). DL: clarification question: DMM deployment model: is it related to the framework works? SG: not looked at that yet. KP: I think we should get done with requirements and gap analysis, hopefully by Christmas and then we need to have discussion on next steps. DL: is this list covered by the gap analysis? SG: I think so, most of it. Victoria? from Verizon: If you look at the EPC and you look at virtualization, if for example SGW, MME are on the same blade, what kind of optimizations would be needed? do we need CP/DP separation in this case? KP: this has nothing to do with coming up with a different architecture. Victoria?: with virtualization, which interfaces disappear, which remain and what remains to be done? AY: regarding of the WG and the way to work, we have good people, but we are lacking energy, because of the time required to finish the requirements and gap analysis. We need to boost the energy level. We haven't had sufficient discussions on the proposed solutions. I suggests to have more discussions on the solutions, to boost energy level and understanding. We can have conference calls between now and next IETF meeting. AY: pay attention to C-SIPTO activity at 3GPP. BH: there is guidance on how to do interim discussion. JK (Chair): keep discussions ongoing.