DMM WG meeting minutes March 5th, 2014, London, UK, Hilton, Buckingham room Chairs: Jouni Korhonen and Dapeng Liu Minutes taken by A. Petrescu Also jabber notes available by jabber minute taker. ** Juan Carlos Zuniga presents, updates from -02 draft-ietf-dmm-best-practices-gap-analysis-03 Georgios Karagiannis (GK): separation data/control plane should be emphasized more clearly. GK: another comment I had about different deployment models, you started about it IETF and 3GPP kinds, we should at least these 2; but maybe also good emphasize expose mobility states. Juan Carlos Zuniga (JCZ): deployment models ok understood, but.. GK: but SDN? depends on deployment models; not this group works on this but expose information that is needed. JCZ: ok. Sri Gundavelli (SG): in the light of new discussion, we need to reflect here what have we discussed, explosive mobility state? Jouni Korhonen (JK): ok we treat your comments as WGLC comments, and have them as issues with document during the WGLC? SG: ok. GK: ok. ** Anthony Chan presents draft-liu-dmm-deployment-scenario SG: If it is virtualized, split CP/UP (Control Plane, Data Plane) scenario, then the traffic does not go to core? Anthony Chan (AC): if not, then it must go through the Cell gateway. SG: but only the CP traffic will go anchor, but UP? Hui Deng (HD): In this scenario there are two possibilities, one through and one through? Brent Herschman (BG): what is the functionality? are you doing types of filtering or deep packet inspection that we normally associate with the normal core at the RM-1 DP, or, how are you going to perform functions on the data path that you perform remotely; is this a roaming functions? BG: In the normal core we do things like policy and online charging; but if you say mobile core thats what we say. But now you try keep the data path from reaching these normal gateways. AC: two different models: one is the one updated, the other is enterprise network, which tries to run lots of functions by itself, but then you still have to subscribe to core. BH: is it a distributed mobile core? HD: if not, everything has to be in the mobile core on top of that? Even if they do LEAP-A they also need to do enterprise, charging policy, that is going to be distributed. SG: this discussion is mixing... from our point of view there's a gateway; we choose a particular mobile node, which is a local gateway. HD: I agree. BH: there are functions in the mobile core that aren't associated with mobility management; if you separate them as in this picture, I am concerned we may loose control; if you talk distribute that core that's fine, then you wouldn't have to go back to the core. AC: different model; these is operators core, this is enterprise core; no need to go to the other. SG: the point of BH is that if policy and charging systems are also distributed, then no problem. (AC continues presentation.) BH: move IP address? Host address? Or mobile address? Can it change? AC: move over here start a new address BH: to the outside world have got the MIP addresses? AC: yes, to some level, up to gateway. Alper Yegin (AY): if you move IP address, preserve IP address, there is an non-shown entity here (on slides), which takes care of traffic steering. AY : Something missing in diagram..? Danny Moses (DM): has to go through an anchor. AC: we can discuss this in the future. Dapeng Liu (DL): you already have a lot of comments and feedback, can you get this to the offline discussion, and on the email list? AC: yes, I welcome all feedback. Thank you. ** Carlos Bernardos presents Open platform demo of DMM SG : we already have problems when marketing PMIP as a term, so MAD-DMM is … (laughs) Carlos Bernardos (CB) : not my fault. ** Satoshi Usui presents measurements of BGP FIB installation DL : comment from the jabber room. DL : you did this test in the MAG, did you consider the transmission collision of one parameter ? (deployment between the routers you would need, no ?) Satoru Matsushima (SM) : focus is on installation time, from the receiving the update message. Not for broadcast, no propagation time, no ? Satoshi Usui (SU): .. Jabber room, question relayed by Bechet Sarikaya Pete McCann is in the jabber room : did you measure the pass time between BGP in and BGP out message ; I measured the router receiving the BGP message, but not the BGP message ; the out of BGP route is subject to BGP completing the time. AY : this sis about FIB installation time, but we also need to take into consideration the propagation delay ; if you could show some more data that includes: how fast the updates are sent out, how to propagate ? Ryuji Wakikawa (RW): what kind of topology, is it realistic ? Not a good idea yet ; but the convergence time, propagation time, we’d need some simulation work ; Kent Leung (KL) : part of this is implementation specific, how many cores how many hardware ? Theres a lot of variation ; I don't know what that number really means, not sure what it really means. SG : if the document can provide some considerations, the size of the domain ? number of routers in the routing domain ; if you define the size, we then know when the host routes process, vs tunnelling based approach JK : this is background, but the demo is today 17h in meeting rooms 1-4 3rd floor ; this is an opportunity for you to check the details of the implementation. JK : assuming that we get the feedback and they have a lot of interesting questions to you (speaking to presenter). ** Sri Gundavelli presents architectural considerations for dmm DM : this is a good description of one possible implementation where the network provides different types of address, and app selects ; but what if net provides one IP addresses, then the app receives, and then requests another one SG : but no assumption I made, but. AY : another case needs illustration :; for one session there may not be one VPN, we could have an IP session that is not anchored. SG : right. Key point of colours on a slide ; these are exact same boxes ; why is the colour changing ? when a user starts on left side, at this point attached to RAN, later, if it moves, then for this client that is the home. Only in a minute ; all these colours ensure that ; at this point, on the right side, traffic ; when going on the other side, for that particular session that particular gateway becomes the anchor. AY : for some of the flows we may not anchoring at all, no instantiation ; SG : you want an address for which no mobility ? AY : yes. SG : thats a property. AY : all these home VPNS are in a rectange, I hope they are not in the same core network, they could be distributed in the Internet. ? SG : yes Marco Liebsch (ML) : this reflects one scenario, an done point in time, cause we also discussed relocation of anchors, then one becomes home , so what happens to colours ? SG : good. SG : route updates interest, a case is user session starts on ‘home’, later it moves of the other side : 2 options, build a tunnel, or send a route update ; that is a session relocation ; if you support relocation as a feature, then pretty much what you say is true, the colour … ; so the home in the previous, no colour change. JK : ten minutes past your slot time. RW : but how do you differentiate between the addresses ? (I can see mobility or no mobility) SG : but, other work, in other WG, you need a structure, a number space ? we are very very sure, thats a long discussion RW : provide an example would be good SG : yes. DM : quick req, if possible ? presentation would be useful for rechartering ? Please let presentation go. JK : yes. (continues presentation) AY : here you have this term ‘home’, what is it ? core network ? is this term interchangeable home-core ? SG : home is where your session is anchored. Home and access the terms we need offline discussions. ML : that caused confusion ; the home is the topologically correctness of the IP address, whereas the access is… so if we do anchor relocation then. AY : on terminology, the IP address may be anchored on the home, access, or near the CN ; SG : needs to be related to the gateway selection. JK : rechartering discussion JK : today, I have preliminary text on charter, I already put out that on the email list. Look at it. JK : out of this session I want to get of the WG about the next concrete WG items ; theres a bunch of different things we could do, but not on all at the same time, most relevant subset we need. JK : we have much like max 4 to 5 documents, busy we’ll be a couple of years. JK : is there anyone in this room who thinks there’s no point in rechartering ? Speak now ? JCZ : repeat the q JK : (repeats) (silence is good) JCZ : people are happy to recharter I think. BH : caveat – we need to break away from the model of legacy systems in, because we have new interactions between boxes, multipath boxes, applications that are going to be running on multiple boxes ; and the future we need to break away from the telecom we had in the past. ** Re-chartering discussion (JK presents Charter text called recharter_draft.txt, I uploaded in into github) JK : we need so have some kind of continuity. Brian Haberman (AD) : I interpret your question, do we have to keep these around for legacy purposes ? No, but DMM gap analysis and requirements, then you d need a brief description of whats been done already. Charlie Perkins (CP) : the new charter seems good quite, but mystified I am but I wonder what i sis about the pros we had motivated the question ; is it the case we eliminate the considerations to traditional telecom ? Id like to find out more about that, if there is such a perceived limitation. SG : another comment on the charter – we agreed we wont define new protocols, we need newer extensions to mip protocols, we should be able to do it even in this WG, Brian do you agree with that ? AD : wishy washy answer, it is not my decision, if there is a consensus for a particular item, and I see it, the nits up to the WG to do , I am not here to mandate SG : at the same time, dmm, and protocol extensions in the same group I think CP : do I understand that its favour to we shouldn't consider doing any new protocol SG : no creating new protocol, no new signalling protocol, I thought about that even at the formation of dmm group, but no other dmm 6 or so.. CP : I don't know whether its possible make crisp distinction new-old, case in point PMIP was created from MIP by adding P to it, specifically what Id be considered the diagram UP/CP, certainly to amend that, in a way to CP an dUPO to interact. AC : just clarify the req didn't say no new protocol, but says we need to consider existing protocol first. CP : I agree with that JCZ : I support ; the way I read the charter, we have the option open, the group to propose what is more achievable ; we are not forced to baseline mip or PMIP. JK : I understood it also the same way ; it is not mandated to used PMIP, or CMIP, can be something else. This does not preclude people working on extensions, if needed on some of Mobile IPv6 flavours in dmm environments, describe in our deployment models and scenarios documents Kostas Pentikousis (KP) : I work on research now more, in the EU projects there is no project on mobility but on SDN, virtualisation etc. KP : VNFpool if it becomes a WG, virtual EPS, mobile core, they can create working groups ; Charter proposal looks now ok, it shouldn't be exclusive, it should be inclusive ; JCZ : I think I have a little … JCZ : mobility with these new optics we should consider KP : I was in I2RS, as brand spanking new as it gets into routing KP : they discussed about using the forces model, vs using the young model ; in all of these WG there haven't been anybody standing there, future EPC, or can be done with DMM, all talk about mobility. AD : I would love to everybody here to be involved in the other WGs ; at IESG they ask do we still do mobility ? If we can cross pollinate with the mobility spaces and all the other WGs (list of), if people willing to go, working on some common grounds, please do that. SG : forces in between, mobility relate discussion there, but no consideration what the mobility considerations can be, its a myth. AD :they are not interested in it because they don't understand the business model, but if someone form the mobility can work with, if not there should be some discussion about why not, that should involve IESG ; SG : the forces example, but they can not build a vertical applications, how to realise, the data plane, and forwarding features, we can leverage their work AD : I agree in the forces case, but in the case of service function chaining – they just get started ; forces discussion, but virtualisation, SPRING, these guys just start, make work with the mobility world, the requirements. SG : plugin the chain, discussion. KP : no such thing as mobile controller (there is a HA). GK : answer to KP, there is an EU project mobile cloud, but it should also be applied to non-virtualised. CP : involving to other WGs ; to LISP I tried, but location identifier separation, sounds like mip, but they are not doing mobility, and then later they decided, they put LISP in a MN, which is complicated ; I understand the value of it but our AD, if you notice such a gap, of need, that some sort of participation we should participate, it would be helpful. Sometimes in the case of service function chaining, they will not want to change their mobility management, they want to create functions, we talk about improving things in this WG, function virtualisation stuff, ONF interesting should it be in IETF, but if you see a need of missing participation, just let us know, delighted well be to help ; AY : NFV, SDN, SFC, not designing these thing sin isolation, applied to 3GPP architecture ; we should to the same by taking 3GPP and demonstrate how our solution gets ; in the past the solution mi pis agnostic, that didn't work well so far ; in the industry more chances ? we should spend some effort in the WG and consider how our solution Zhu Lei (ZL) : more interest is still there in mobility, and people here are very relevant, but 3GPP is there but also quite interesting in… BH : not aligning with networks as Alper said, but we should be aligning with apps, there is multi-path, MPTCP, WebRTC ; they all do these things ; they can be wifi, wireline, other things ; when they do multiple screens, thats mobility, where are we in that space ? What should web e doing to facilitate that mobility ? There no one operator which , theres the application owner, emphasis on services. DL : application layer is fascinating potential future ; I am not worried either lisp had the opportunity to replace the EPC, but I can predict the future of the virtualisation functionality ; 3GPP mobility management, special is about virtualised people, maybe the one chance in the future, I do see the potential when virtualisation comes out the anchor point, the interfaces could be organised by compatible with mobility ; separation UP/DP is only touching on … its not touching on virtualisation. Andrew (XA) : consequences of DMM solution should be applied ti 3GPP systems ; but 3GPP has own solution that has quite good performance ; but there are also challenges, e.g. we envision in the future we use much more small cell, in which case the coverage of small cell, in this case the mobility is very huge, so I think for our current, the dm mis good to cover these challenges, but my concern how can we provide the performance of 3GPP mobility ; in 3GPP they talk of handover interruption of 50ms ; I want to say if we provide new mobility management then we have to provide a certain point ; virtual network is one point ; another selling point is why don't we always thing mobility at network layer, maybe combine with MPTCP, maybe reuse link layer. DM : ok, we have been discussing for about 30min whether we are entitled to exist or not ; many people in the room think this is an important area to explore ; the interim meetings we had prove that this is important ; lets spend the rest of the minutes on the ; we started various activities, but apart from reqs and gap analysis we didn't focus ; charter misses – try to a final not too large list of work items we try to work on. The last slide of Sri was a good basis, something we could discuss and agree on. JK : virtulisation, reference I should add in the Charter. CP : not interrupting you ; I read a new charter, it needs a bit of words smithing and I think its a good basis to move forward ; JCZ : the charter go in the right direction, I have a couple of comments only if you want, now maybe, there i sa part of it, « however the mobility management in a limited area is not strictly limited to IP mobility protocols » not sure autonomous system, but I would take that out. JK : administrative area, one administration, one AS, multiple AS, but same management, people know whats happening inside of it. JK : example of routing protocols, routing area might be multiple ASes but still something you could manage, not something you could use of global scope : JCZ : virtualisation I hear, so this is a restriction we don't know there. JK : I will propose more clear. RW : I prefer having this keep in the charter ; because in operators today, we have that ; of course mobile IP is IETF, but in real operation better have something like this for operations ; we lay have clarification, but I want that in charter. AY : some language is needed about capture case of smaller domain may use BGP, this text is a placeholder for this. Serge Manning is SM SM : protocol stuff bothers me, but are we going to expose this to applications, we should be more clear about the boundaries. AC : the text is not MIP, it says first reusing IETF standardised protocols, it didn't say MIP ; if we talk about forces they are not excluded. JK : mobility aspects, virtualisation, areas of other stuff, continue work on this charter, before next IETF, immediately in the week at this IETF, get to the continuous discussion hopefully we have a text we could proposed to the AD, and ask what we should be doing, we need to make sure we nail down the actual milestones we need to work on first, they are actaully the actual documents we will do. JK : thats all. JK : we should have an optimistic thinking; we should have a charter proposal by the end of this month. JK : if needed we will send the details of the Webex of the interim.