* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dmm Status Pages

Distributed Mobility Management (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2012-Jan-10 —  

IETF-103 dmm minutes

Session 2018-11-08 1350-1550: Boromphimarn 1/2 - Audio stream - dmm chatroom


minutes-103-dmm-00 minutes

          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
          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
          Sri: No value in industry and no interest. As coauthor and chair its
          better to withdraw the document.
          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.
          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
          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
          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
          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
          Marco: we have been through 12 revisions. However, we need more
          reviews. We got one from Carlos but we need further in the information
          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
          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
          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.)
          John: No comment on this. But there is work on ACTN. Techniques are
          different but complimentary.
          8.- Time Sensitive Networking for 5G, Kasu Kasu
          Kasu: This is early. Its just a proposal. Welcome other members to work
          on this with him.
          10.- SRv6 Mobile Use-cases, Pablo Camarillo
          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.

Generated from PyHt script /wg/dmm/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -