Skip to main content

Minutes IETF103: dmm
minutes-103-dmm-00

Meeting Minutes Distributed Mobility Management (dmm) WG
Date and time 2018-11-08 06:50
Title Minutes IETF103: dmm
State Active
Other versions plain text
Last updated 2018-11-13

minutes-103-dmm-00
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.