Dmm Status PagesDistributed Mobility Management (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2012-Jan-10 —Chairs:
IETF-103 dmm minutes
Session 2018-11-08 1350-1550: Boromphimarn 1/2 - Audio stream - dmm chatroom
DMM Working Group - Bangkok IETF Meeting Thursday, 8 November 2018, 13:50-15:50, Boromphimarn 1/2 Chairs: Sri Gundavelli and Dapeng Liu (absent) Minute taker: Satoru Matsushima, Pablo Camarillo Jabber Scribe: 0.- Administrivia & Intro, WG organization & milestones, Sri Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dmm-dmm-working-group-status-00 draft-ietf-dmm-ondemand-mobility Suresh Krishnan: Content is in WG but not very clear. Would be useful to get implementation commitments; or alternatively send email on the mailer asking whether there is interest in the draft. No commitments from vendors is required but we should have some requirement. Suresh: Socket API definitions done by POSIX, not by us. We should make it more generic. Charlie: If we can use sockets, are there generic APIs? and then some statements on include files -------- draft-ietf-dmm-deployment-models Sri: No value in industry and no interest. As coauthor and chair its better to withdraw the document. -------- draft-ietf-dmm-srv6-mobile-uplane Sri: There should be more discussion on the mailer. Satoru: EndMarker should be part of a separate document. Satoru: The work is almost done. There should be some editorial work for clarity done. Should not get very delayed. Sri: Shall we run it through spring? Satoru: No Suresh: No, but we should get routing review. Requests Sri to assign reviewers from WG. ------- draft-ietf-dmm-pmipv6-dlif Carlos: Two detailed reviews since last IETF in the mailer. We are still adding the comments from Lyle Sri: There should be further comment on the mailer and you should get revieweres from DMM. ====================== 1.- SRv6 Mobile Userplane, Satoru Matsushima Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dmm-srv6-for-mobile-user-plane-03 Charlie: Regarding Args.Mob.Session. Args is a generic name. Satoru: The reasoning for starting with word "Args" is the SRv6 format, but we could try to improve readability. Kentaro Ebisawa: Sent two comments on mailer. 1.- Pseudocode for End.M.GTP4.E is inacourate (email sent on the mail). He has sent a proposal on the mailer. Please review.; 2.- T.Tmap. Translates GTP to SRv6. If there is any reason he suggests we rename it and add GTP into the name. Satoru: Both issues should be addressed. Suresh: SRH insertion concern. Conversation happened on 6man. This draft should not get ahead of 6man discussion. Two proposals: 1.- To propose the header insertion draft is a pre-condition for this draft and there is no progress until draft-voyer-6man-extension-header-insertion progresses 2.- Keep it out and add it in later. Satoru: we should be able to minimise dependency. Suresh: Has dependency on SRv6 (SRH and draft-filsfils). We need to progress those. Reviwers: Carlos Jesus Bernardos, Miya Kohno, Kentaro Ebisawa, Hannu Flink, Takuya Miyasaka. ====================== 2.- Distributed Mobility Anchoring, Carlos J. Bernardos Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dmm-distributed-mobility-anchoring-00 Carlos: Concern is to get volunteers to review from WG. Reviewers: Charlie Perkins, John Kaippallimalil, Marco Liebsch ====================== 3.- Proxy Mobile IPv6 extensions for Distributed Mobility Management, Carlos J. Bernardos Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dmm-proxy-mobile-ipv6-extensions-for-dmm-00 Carlos: Document is stable. Appreciate more reviews. From authors point of view only missing is review. Sri: Implementations? Carlos: There are implementations. We showcased it 4-5 years ago an implementation on IETF 2014 Berlin and another one. Publicly available on GitHub. Sri: Lets ask for additional reviews. Reviewers: John Kaippallimalil, Marco Liebsch ====================== 7.- A Smooth Migration of Mobile Core User Plane from GTP to SRv6, Arashmid Akhavain (Remote) Arashmid: PoC contains the first two steps of the set of demos that they will develop. The ideas where discussed in previous IETF and are based on SRv6 Mobile Userplane draft. First approach is smoothly migrate GTP plane without modifications on the control-plane based on 3GPP requirements. Arashmid: Demo available outside room. Please view and provide comments. Next step could be IPv4+IPv6 network. Maybe. Suresh: SRGW to Prefix. Do you assume that is a /32 prefix? Otherwise it will not work. Arashmid: yes. Suresh: Addresses are reversed. Why? Arashmid: I followed the structure of SRv6 mobility draft. It would be an option to define here the SID format, but likely it will be 3GPP the one defining it. Suresh: What happens if IPv6/GTP packet? Arashmid: This will be the next step of the demo. We will need an SRH. Suresh: But where do you encode TEID? Arashmid: Will use an SRH with another SID where this is encoded (in the additional SID). Sri: next-steps? Arashmid: Have received interest from several companies to work on this. We need to evolve this. Hopefully next we bring Sri: Please document any issue. Its the useful part of the draft. Suresh: What is the plan wrt to this draft? Arashmid: It should be a feedback to Satoru's draft. ====================== 4.- FPC Update No presentation of slides. Sri went through slides quickly and triggered discussion. Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dmm-protocol-for-forwarding-policy-configuration-fpc-update-00 Marco: we have been through 12 revisions. However, we need more reviews. We got one from Carlos but we need further in the information model. Sri: Should the yang model be separated or not? Marco: Discussion should be orthogonal. Suresh: I read the doc. Not critical review of document, however document has improved. It will be challenging in IETF. No good suggestion on how to trim it down? However, spliting the document is also negative. Neutral on the decision. Suresh: Should get some reviews from the working group. Sri: What about other groups? Suresh: We could shoot for yang doctor review. Sri: there have been many reviews of the draft. Marco: Its a good proposal to ask people from policy and mobility background to review. Charlie: We should get a solid architectural and informational yang that should be applicable. Example: some people might only be interested in PMIP or 3GPP part. Suresh: Charlie, which should be the canonical? (how to avoid both not getting out of synch) Charlie: YANG part should be subordinate to the other document. Suresh: Maybe the YANG should be the main one. ====================== 6.- User Plane Protocol and Architectural Analysis on 3GPP 5G System, Shunsuke Homma Slide: https://datatracker.ietf.org/meeting/103/materials/slides-103-dmm-user-plane-protocol-and-architectural-analysis-on-3gpp-5g-system-00 Shunsuke: [Errata on the update slide] ver.02 is the version for arch-req section slide-5. Shunsuke: Should this document be informational RFC? Suresh: Fine with adopting the document, but has no visibility on 3GPP. Hence would like official communication. If 3GPP is going to make a decission based on this, Suresh wants to see this dependency. Suresh to follow up with Georg and Satoru. Georg: Adding this to the study will not help you. This does not put pressure from 3GPP to IETF to progress this unless CT4 takes a decission to use this. Georg: having the draft adopted makes 3GPP understand that draft is progressing and there is interested from the WG. So it should be adopted. Suresh: If the only use is to guide the study item, what is the value of this document in the IETF archives? If 3GPP will not use this, what is the value? I would keep progressing the document, adopt it as working group, but perhaps might never be RFC. Sri: There are other documents that are doing analysis and are useful in archive. Suresh: 3GPP is making the decission on the study item. This is very valuable, but if the decission is on 3GPP then Suresh does not see the value. Sri: if we analysie the LS statements from 3GPP, 3GPP encourages IETF to work on this kind of analysis. Pushing this as a draft is good. Satoru (3GPP raporteur): The document is valuable for 3GPP for doing the analysis. Further on, this document should be useful in the long term Kiran Makhijani: Will 3GPP ever refer to this document? Georg: You cannot assume that 3GPP will reference it, and you cannot assume that 3GPP reviews it. It will be useful for 3GPP, but no assumptions can be made. Georg: if this document is valuable for your own purposes, keep progressing it. Suresh: What if we send this in a liason statement to 3GPP? Other option is adding it as an archive in IETF. Is there a difference wrt to value in each option. Sri: This work has a value. Dave Allan: Up to the discussion, the Liason discussion has been that we would not provide an analysis. We would online provide the protocols that we are working on. Sri: We are never going to recommend a single protocol. We are doing the technical analysis. Dave: This is similar to other cases. What we sent back to the CT4 liason is not what they asked us for. Georg: This is only your working group evalation. This is valuable work on standalone. But not for 3GPP. Dave: At the very beginning the purpose of the draft was stated, it was not a DMM item. Satoru: Believe that the motivation comes from both IETF and 3GPP. Its positive to describe in IETF what the 3GPP system looks like. ====================== 5.- Traffic Steering, Marco Liebsch Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dmm-control-data-plane-for-n6-traffic-steering-00 Marco: Is this useful work? if yes, requests working group feedback. Sri: 3GPP does not define anything on N6. Do you think this will change? Marco: No. Satoru: What functions do you expect to be deployed on N6? Note that 3GPP defines already some functions for charging, so its not clear what is the functionalities deployed on N6? Marco: Based on the use-cases we see value in steer traffic on N6. We may have to apply more policies, like MPLS labels or QoS treatment. N6 networks tend to get large. DPN can be any protocol, but it should be programmable. Satoru: If 5G architecutre, 5G core provides interface to allow application to put the policy that affects the dataplane. Marco: Using the AF which is in 3GPP. However, the interfaces in between the AF and 5G core are being defined in 3GPP. The AF maybe associated with any other controller. John: In 3GPP most of the time the UPF and AF and so on are tighlty couple. The architecture here is decoupled. You will need some way to decouple the policies, and make sure that the traffic steering work done by 3GPP does not collide with this. Suresh: We need clear separation in between things to do. What do you want to change in the architecture vs protocol bits. Changing the architecture itself, does not make many sense -we dont have a good track record of it-. Marco: I dont think we break what UPF does. Maybe, if the UPF is deployed in a particular way then we might break things. Georg: you have to define whether you want this on 3GPP or not. Whether it is the end goal. If you want to have this on 3GPP then you need 3GPP to actually send an LS requiring this. Then 3GPP architecture should study, then the protocol group looks in. But what you are doing now is something new, and if we want this then we need really people that goes to 3GPP and actually push for it. You need to have a high level requirement from users that mandate the requirement for this. Those will be discussed on 3GPP SA1 and that might take a while. Marco: There are two use-cases. Second use-case is fine. First use-case does modify 3GPP. This should go through 3GPP. ====================== 9.- Transport Network aware mobility in 5G, Kiran Makhijani (Kiran is not author of document. She is presenting on behalf of Uma. Document was presented on IETF102.) Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dmm-5g-backhaul-network-with-ppr-and-mobility-scenarios-00 John: No comment on this. But there is work on ACTN. Techniques are different but complimentary. ====================== 8.- Time Sensitive Networking for 5G, Kasu Kasu Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dmm-time-sensitive-networking-for-5g-01 Kasu: This is early. Its just a proposal. Welcome other members to work on this with him. John: ====================== 10.- SRv6 Mobile Use-cases, Pablo Camarillo Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-dmm-srv6-mobility-use-cases-00 Pablo: Describe motivation and applicability for mobile user plane. Next step is to cover missing use cases. John: intend to be standard? Pablo: No. John: comments are regarding impacts to 3GPP arch. Will sent comments to the mailer. Pablo: Call for participants to join as coauthors or provide feedback on the mailer.