* 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: Éric Vyncke, Suresh Krishnan | 2012-Jan-10 —  

IETF-105 dmm minutes

Session 2019-07-24 1000-1200: Notre Dame - dmm chatroom


minutes-105-dmm-00 minute

          Note: David I Allan & John Kaippallimalil
          Title: Administrivia & Intro, WG organization & milestones
          Description: Agenda, Note-taker negotiation and WG Progress Update
          Presenters: Chairs
          new co-chair - Satoru Matsushima
          Scribe: Dave Allan
          FPC document split discussions due to the size of the document, hard to
          get reviewers
          Suresh: Reviewer pool for each is different. Can look for YANG best
          practices separately.Not everyone needs to read the YANG module. Three
          independent steps. Document adopted procedurally as it was a split of
          an adopted document simply to facilitate progress.
          Sri: Those familiar with YANG semantics can look that over. FPC needs
          to be republished.
          3 other documents passed WG last call. Suresh: Want to get these docs off
          my queue in the next two weeks. On demand mobility needs some discussions
          resolved, Way forward not clear. Not too much WG action required. Hope
          to resolve by Friday.
          2. Topic Name: SRv6 Mobile Userplane
          Presenter: Satoru Matsushima
          Draft reference:
          Summary of updates 04 to 05
          Stateless mapping rule update.
          Pseudo code updates for mappings
          Hackathon Feedback
          - all GTP-U IWF implemented in FD.io VPP
          - New end function to support drop in scenario not in the document. SRv6
          transiting to GTP-U. In the middle of the path the SRV6 plane can be
          manipulated due to operator policy.
          Suresh: What is the use case for drop in? A: To map into N6 interface.
          When function is in the DN. And routing differentiation based on SID
          instead of GTP-U end point.
          Suresh: But you are just popping IP out into N6. Second use case is
          roaming. AD hat off it seems reasonable.
          Mailing list comments:
              - can we add drop in mode as described at IETF 103 (GTP/SRv6/GTP
              -     Does the draft need to describe it.  Sri: Chair hat off,
              it would be better to describe it.
              - when is it required to use args.mob.session
              -     Helps when sessions aggregated on a SID
              - doc should elaborate more on arg.mob.session use cases.
              -     Add some text, specific sentence proposed
              - how does SRGW learn SID list to a DA, does it need to be per session
              -     modify text in 6.3 to indicate SID can be shared
              - use of term "anchor" not clear in the document
              -     resolution TBD
             Sri: anchor is a routing end point (UE IP address is topologically
          ·         Arashmid:  they are all UPF's.  Changing the term might solve
          the problem.
          ·         Sri:  UPF is not an IETF term.
          ·         Arashmid: Do not want to find every UPF and use case.
          ·         Suresh:  Use 3GPP as examples, not definitions to avoid
          overloading what we are saying.
          ·         Marco Liebsh: We could use DPN DPA, data plane node/anchor
          and go around this.
          ·         Uma: We do not have to redefine 3GPP stuff. Lots of stuff LI
          etc. happens at a UPF.
          ·         - what about translating GTP PING?
          ·         -     cover GTP messages in a separate document (e.g. end
          ·         Comments effectively rejected
          ·         - what is specific table
          ·         -     keep current text
          ·         - comment on downling 5.1.2
          ·         -     keep current text
          ·         - 5.2 what about SID overhead and header compression
          ·         -     keep current text
          ·         Sri: Is this specfic to this work item or SRv6 in
          general... Neither(?)
          ·         -
          ·         - downlink IW with IPv6 GTP
          ·         -     N4 signalling is one solution --> keep current text
          ·         -
          ·         - 6.2 end.map
          ·         -     how to populate mapping table is out of scope
          ·         - 6.2 segment list is SIDs, text to be added to clarify
          ·         Have VPP and P4 code implementations. Looking for other
          ·         ready for WGLC after comments resolved.
          3. Topic Name: Transport Network Aware Mobility for 5G
          Presenter Name: John Kaippallimalil, Uma Chunduri
          Draft Reference: draft-clt-dmm-tn-aware-mobility-04
          Problem no clear or standard mapping function between SSTs (eMBB, URLLC,
          MIOT) and underlay transport.
          QoS characteristics need to be preserved across mobility events.
          Objectives: framework to apply other IETF technologies, how to use PPR,
          provide a mapping function, and a reference arch.
          Non--objectives: replacing GTP
          Sri: Was this presented in 3GPP.  Uma: No, CT4 delegate had significant
          changes, but this is IETF work.
          Dave: Can you elabrate on provide a clear mapping - an API?
          Uma: what needs to be done to be mapped to an underlying tunnel
          An Nguyen: Will this touch the MPLS layer.
          ·         Uma: IETF has lots of TE technologies, we do not want to
          touch anything there. Want to show PPR specifically and a framework.
          An: How does QCI mapping and DSCP play into this.
          Uma:  UDP source based mapping to SR tunnels is one way.  In 5G there
          is a QFI field in the GTP header.
          An: Would you coordinate this with 3GPP folks?
          Uma: At some point yes.
          An: Would be good to get coordination people involved.
          Suresh:  We need to sort next steps if this is targeted to 3GPP. How do we
          communicate this exists and does it meet their needs? I think other work
          besides CT4 is needed so a liaison or similar.  We had a coordination
          meeting on Monday.  Idea is that this goes on a dependency list. That
          is independent of what happens in IETF, but if you want something to
          happen in 3GPP you need to do this.
          John: In 3GPP there are multiple groups we need to consider, SA5, SA2
          architecture does not think anything is needed at this point.
          Suresh: I can ship it off to a wide distribution list.
          John: Trying to minimize overlap to ensure it is clear this is IETF work.
          Uma: They need to know about it as it relates to their technology.
          Suresh: Best to share status early, 3 month hysterysis.
          Changes to 04
          - ch 2.2 mapping between 5G and transport slices.
          - revision of integrated approach in ch 2.1, and PPR ch 3
          - introduces MTNC - mobile transport network context
          -     maps 5QI to transport slice instance
          MTNC is carried in IP packet header extensions
          This as presented in TEAS.
          Uma: one problem with version 3 was we tried not to change the GTP
          packet. Mapping QFI was difficult due to the depth you had to look in
          the packet.
          John: Can provide a mapping downstream.
          Eric Klein: So the packet is GTP,  and you are further reducing the MTU
          by 12 bytes?  A: Yes.
          Satoryu: One idea in bits and bytes to carry the MTNC. You mentioned
          SRv6 could be a transport. The SID could indicate this. A: Agree.
          If I understood you correctly.
          Uma: One request for the WG is if there is another approach that does not
          require packet modification, or looking deep into GTP extension headers.
          Eric:  The destination is gNodeB to UPF?
          John: Can be gnodeB or UPF.
          Eric: Can these things have entire /64s to themselves. Put the ID in
          the lower part of the address?
          Uma: Great ID.
          Eric: Is this public network, for v6 you can do this, for v4 use 12
          extra bytes.
          Satoryu:  If not touching the existing architecture and needs to be a
          more generic solution. Touching some sort of VPN solution, and WG.
          John: I can work with you on this.
          Looking for comments and suggestions.
          4. Topic Name: User Plane Protocol and Architectural Analysis on 3GPP
          5G System
          Presenter Name: Takuya Miyasaka
          Draft Reference:
          Background of this draft has not changed.
          Major updates:
              - slice type description (4.1) eMBB, uRLLC, MIoT, V2X (Rel 16)
              - [missed other changes]
          PFCP State Information on N4
          John: N4 and PFCP, are you also considering N2, A: currently no.
          Supporting URLLC in 23.501- redundant UP paths using dual connectivity
          (redundant transmission, 2 UPFs/RAN fns, 22 I-UPFs and N3/N9 tunnels)
          GTP-U sequence number to detect duplicated packets works in simple
          I-UPF scenario must transfer the sequence number across GTP tunnels.
          Sequence number and other options to carry this information under study
          in 3GPP.
          5.Topic Name: YANG for Protocol for Forwarding Policy Configuration (FPC)
          Presenter Name: Charles Perkins
          Draft Reference: https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-yang/
          Charlie unable to attend.
          6. Topic Name: Control-/Data Plane for N6 Traffic Steering –
          Applicability to MEC for automotive use cases
          Presenter: Marco Liebsch
          Draft: https://www.ietf.org/id/draft-fattore-dmm-n6-trafficsteering-01.txt
          Automotive use case - may have to move the services closer to the user,
          and hence the UPF is closer as well.
          This should be done without unambigous traffic routing between the UPFs
          of that session.
          Uses routing policies to accomplish this.
          N6 PEPs - loose vs tight coupling
          Considering loose coupling where the policies are independent of mobile
          core (i.e., not via N4)
          The draft supports both loose and tight coupling
          Contributing some of these aspects to ETSI MEC
          MEC deployment with polcy manager DPN colocated with the UPF.
          John: If you have a network between AS and UPF are you covering the
          scenario where it is a nonp-topological route to the UPF.
          A: If you move any of the end points we deviate from standard routes,
          and therefore need host routes.  This is done by policy controllers. If
          the car is moving at some point you may make the decision to relocate the
          edge. We try to leverage the VPN overlay on N6 to keep this procedure
          as independent of the 5G control plane as possible. Investigating how
          far we can take this both intra and inter domain.  A lot of technology
          challenges. Whatever we can do to support this on N6 we want to
          investigate. Employ SR, header rewrite, tunnels.
          Cross domain handover and edge relocation case.
          John: You mentioned preloading policy, is predicting the path the solution
          to sorting out control latency?
          A: We look at proactive vs. reactive mechanisms. If you can select
          target beforehand, you can set up resources.  One of the last steps in
          our scenario. We can prepare resources in advance, something we currently
          look at.
          Sri: Prediction mechanism?
          A: we are investigating.
          Interested in WG adoption, liaising to 3GPP.
          Sri: Looking for WG feedback, no action beyond that, right?  A: Yes.
          7. Topic Name: Enterprise IP Mobility - New Requirements
          Presenter Name: Charles Perkins
          Draft Reference: None
          Charlie unable to attend.
          Meeting closed.

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