Minutes IETF105: dmm
minutes-105-dmm-00

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: https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane

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
    translation) -     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
   configured)
·         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 marker) ·         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(?) ·         - <missed comment> ·         - 5.3.1.2
downlink IW with IPv6 GTP ·         -     N4 signalling is one solution -->
keep current text ·         - 5.3.1.3 ·         - 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 implementations. · ·         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 (adaptation) 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:
https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-analysis/

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 scenario. 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.