* 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 —  
Chairs
 
 
 


IETF-106 dmm minutes

Session 2019-11-18 1550-1750: VIP A - Audio stream - dmm chatroom

Minutes

minutes-106-dmm-00 minute



          DMM Monday 11/18/2019
          Scribe #1: Dave Allan, Ericsson
          
          Shunsuke: CT groups looking to complete work for release 16 in March. Can
          we go to last call.
          Suresh:  Requires WG review. We can also send a liaison.  Cannot see a
          way to complete this by March.
          
          Sri: Status of different items.
          FPC work ground to a halt, need a way forward.
          Distributed Mobility Anchoring, shepherd notes need to be redone.
          True for proxy MIP as well.
          Suresh: On-demand mobility management has an RFC number assigned.
          It's done.
          
          SRv6 for Mobile User plane /Pablo
          - summary of updates, removed insertion. Added drop-in, double ended GTP
          interworking. removed support for unstructured PDU session type. Changes
          to handling of ethernet means new allocations would be required.
          
          Carlos: willing to review.
          
          User plane message encoding-00:  Tetsuya Murakami
          
          Goal is to carry GTP-U message information.  Proposes carrying information
          in the unused tag field in the SRv6 header (?) .  Proposed bit field
          definitions for end-marker etc.
          
          Add a TLV to carry 3GPP information.
          Penultimate Segment Popping must NOT be used.
          
          Proposed for WG adoption.
          
          Uma: Purpose is to remove GTP completely and replace with SRv6.   Is there
          any use case to send from the UE itself?
          Tetsuya:
          Sri:  Does not extend to the UE.
          Suresh: Spectrum is expensive. Do not want GTP on the air.
          Dave: Stuff covered is either carried over PDCP or only of significance
          to the gNodeB. Do not need GTP to UE.
          
          Sri: Need more feedback from WG and the AD.  Keep doing the work and
          we'll see about adoption.
          
          Transport Network Aware Mobility for 5G, Uma, John K.
          
          Current version narrows down choices for MTNC-ID in meta data.
          
          Looking for mapping from PDU session layer to transport network paths.
          Sri: Overlay to underlay mapping is not a new problem. Right.
          Uma: What has been deployed used non-standardized ways of mapping. We're
          looking to streamline this.
          
          John:  Wanted to converge on one solution. Added option for encoding
          context ID in th outer header--> source UDP port.
          Sri: Where do you get this transport network context?
          John: It is not IETF work to come up with this mapping. Believe they have
          also selected ACTN, but details still being resolved in SA5.  TNF is
          a logical function, interfaces are IETF. 3GPP slice aspects NSSAI is
          related to what a user is supplied. May be 1000 customers and 3 slices.
          Impacts N2 and N4.
          Sri: Today you do mapping at a session level. What are the advantages
          of at a slice level?
          John: DSCP is not immutable. QFI is too deep for packet inspection.
          Dave: Source port normally used for ECMP. Is this turned off?
          John: in the text. Only certain ranges used (?)
          Satoryu:  You are proposing using the source port for mapping. What WG
          would define this.
          Uma:  This is a local mapping.  Not a WG problem and is backwards
          compatible.
          Suresh: If rewriting UDP ports, are you redoing the checksums?
          Uma: Done at the UPF where the UDP header originates.
          Xuesong: VLAN should not be excluded.  Can user other encaps to respect
          the information
          John:  We can include that
          Marco: UDP is a bi-directional thing.  Does the value need to be
          symmetric.
          John: We are considering unidirectional flows. Assume some symmetry. If
          using a range on the upstream, range does not need to correspond.
          QFI itself insufficient.
          Tasuya:
          John: Range of the UDP port handled by the IP part.
          Tasuya: So do not use existing PFCP
          John: What about WG adoption?
          Sri: Can ask the group.
          Xuesong: Map in the RAN to the backhaul, this is isolated work.
          Sri:  How to take this up.
          Xuesong:  In the same WG.  Not sure these are tied together and could
          be different drafts.
          John:  What part?
          Xuesong: The solution space.
          Carlos: Also willing to review.
          Sri:  Need more discussion, good feedback.
          
          Architecture Discussion on SRv6 mobile User plane, Miya Kohno
          
          How to map mobility data plane.  Suggests SRv6 is the right choice for 5G.
          Suggests an additional user plane ID is required for slice mapping.
          PE redundancy is an additional requirement.
          Goal is to have the UPF be part of the TN and not a CE.
          
          3GPP entities do not care about IP routing??   Sidecar proxy can take care
          of communication state exchange.  BSID can be used for topology hiding.
          URLLC with duplication and elimination requires modification of GTP-U.
          Proposed for discussion.
          
          John: Good points on URLLC. How does SRv6 allow paths to be disjoint?
          Miya: Could provide TI-LFA and other tools. SR aware entities can directly
          control the mechanisms.
          John: With a chain of N3/N9, how does SRv6 help?
          Suresh: What is this a separate document?
          Miya: SRv6 mobile user plane document simply describes the protocol. I
          wanted to discuss more the architectural implications.
          Suresh: Text is useful, how it proceeds to be discussed. It is pretty
          dependent on other stuff. This comes up in IESG as supporting documents.
          If it is to be separate and progress need to think about the write up.
          Sri: Good points.
          Uma: Good questions are asked.  Can collapse GTPU and SRv6.  We are
          envisioning a future of IPv6 only transport. When we started it ws NS1U.
          This is a bigger discussion.
          Marco: Service mesh, what does this have to do with slicing. It is an
          implementation matter.
          Miya: Conventional box thinking needs to be evaluated.
          Marco: What about proxies... .
          Miya:  IF there could be a proxy that could do all routing and forwarding
          stuff and it sits in the host. We could provide routing in host.
          Rajeev: Liked the side car analogy, so the proxy was adjacent to the
          application itself.
          Marco:  Sidecars function at a DHCP level.
          Rajeev: There is also the notion of application routing. Lines are
          blurring and have been for some time.
          Suresh:  If in a sidecar, the app does not need to know about it.
          Sri: Good work, needs more discussion.
          Uma: This and the last presentation are very much connected.
          
          Mobility capability negotiation and protocol selection  Zhiwei
          
          Two categories, network and host based solutions.
          
          Suggests a negotiating discipline.
          
          Possible solutions for negotiation.
          ICMPv6 gets a new option.
          
          Suresh: Everything you say has been tried before. 2007-2008, it never
          worked. If the network can do it, it will do it.  CMIP vs PMIP. The
          problem is not technical. There is no deployment scenario where this
          will be useful.  There is a past history of failure.  Think about where
          and how you would use this.
          
          Sri: May want to work with a few people, get some feedback, and decide
          whether to pursue.
          Rajeev: For an endpoint attached to cellular, going to a site GW, where is
          this message going? Could be a side gateway.  SO this notion of something
          in the RS an RA to allow mobility to work, needs to be compatible with
          outside of the cellular world.  It would have a low footprint.
          Suresh: The other ones were RS RA based.
          Uma:  Why did it fail, security or what?
          Suresh: Not anchored in architectures anywhere.  For good or bad,
          architectures done elsewhere.  Stuff need to be anchored or it goes
          nowhere. Deployment support. Everything Rajeev said was looked at.
          
          YANG for Protocol for Forwarding Policy Configuration (FPC)/ Satoru
          
          FPC did not touch any over the wire protocol. Decided to define a YANG
          model to provide an API.
          
          After the update by Charlie, there has not been further work, so the
          draft has expired.
          
          Continuing to pursue this dependent on group/industry interest.  Comments?
          
          Marco: co-author. This stuff is pretty stable. Since we have two pretty
          mature parts, need to review. But we should progress them. Need reasonable
          reviews to proceed. It would be a pity not to proceed.
          
          Sri: Move this to the mailing list.  Need to go through the process and
          get some reviews. Suresh agrees.
          
          Session Closed
          
          



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