Minutes for DMM at IETF-91
minutes-91-dmm-2

0900-1130 HST Wednesday Morning Session
============================================
meeting chaired by Jouni Korhonen (JK) and Dapeng Liu (DL)
 Alper Yegin is AY presents
 AY announces: SIPTO accepted as study item in Release 13 3GPP SA2
 AY: SA2 busy with many items
 AY: prioritization discussion in plenary
 AY: make sure you support C-SIPTO
 C-SIPTO is?
 AY: presented at last IETF
 C - coordinated SIPTO
 slide 3
 slide 4
 (the slidesets are at
 https://datatracker.ietf.org/meeting/91/materials.html#dmm ) Sri Gundavelli i
 sSG SG: terminology, SG: what if two apps are using this 'sustained' address? 
 to which app? AY: if 2 flows use it, release only both terminated. SG: goal
 was to reflect IP address properties? SG: color address? SG: tie to app? the
 property of address changes depending on app lifetime AY: no, not changing by
 app AY: attribute belongs to IP address SG: give IP address to terminal, no
 app, then what is the property of the IP addresS? AY: depends on the system
 SG: understrant the intent SG: somehow the temrinology needs work AY: term
 sustained not comfortable, if better fine Danny Moses is DM DM: these types of
 addresses are services provided by network DM: when an app starts, it could
 require such an address DM: but if server needs an address... SG: stable
 means... DM: th emeaning is the type of service we receive from the network.
 Charles Perkins is CP
CP: if several apps use same sustained address, t1, t2, if addresses are
different per app then theiyre shortlived, but better have a single address for
both apps. AY: not disappear per flow CP: apps can not know AY: all the app say
is that it needs a sustained address... CP: should keep in mind this. SG:
examples of apps using different types of addresses? slide 5 slide 6 SG:
extensions to 5014 ? SG: generalized? slide 7 Brian Haberman BH: people are
going to say - you want all the apps to know whether or not they operate on a
mobile node? BH: every app needs to source address select that? AY:... BH: the
apps folks will say that. metricamerica joins the room DM: if you want
optimization for extra servers you should know about this DM: if no extra
service, then apps should not necessairly know CP: the apps need to know?  but
th emobile will just offer fixed addresses for all apps? AY: yes, for those who
ask slide 8 Fred Templin on use cases for prefixes and planes and moving
networks Satoru Matsushima i sSM SM : support for prefixes AY: the apps dont
speak in terms of prefix terms SG: always give prefixes to terminals AY: DHCP
gives address SG: in mobility architectures, address allocation scheme in 3GPP
AY: in WiFi architectures? SG: ask an address, nothing changes, property of
prefix AY: more of an issue of item 2 and 3. AY: ... SG: in the backend, the
address is from prefix, ... SG: even for a given address, the address is on a
given iface. SG: for delegated prefix is for inside SG: agrees aith alex's
question... Chair: you run out of time slide 9 slide 10 slide 11 Dapeng Liu DL:
if mobility support by app, how does the termoinal registration know that? AY:
need to discuss that DP: how many docs of this work team want to have output?
AY: seems for item 1 1 doc, item 2 and 3 may be 1 or more AY: four or five
Serge Manning is SM SM: boils down to the address type the mobile node asks
for. AY: ... DL: please discuss on email list H. Anthony Chan presents (HAC)
Page 2 Page 3 SG: summarize - general mobility anchor functionality... some
mobility anchor SG: confused about Internet routers... Sharon Barkai is SB SB:
anchor is a record of context SB: there is the record and the record coming to
the data HAC: th ebinding? SB: yes SG: enhanced anchor functionality SG: what
is enhanced? SG: there are std functions already used... HAC: look for... Page
5 SB: ( 2 ) assummes a correlation of where it is SB: update routes not
sufficient HAC: proposal to use BGP update upstream SB: need to show up where
it is possible, not everywhere AY: could be helpful AY: depends on deployment
JK: need host routes at some point. SG: clarify I may, you talk anchor
functionality SG: in anchor based model there is no host route SG: ... HAC: the
anchor may move SG: move the anchor then ther ei shost route SB: anchor is a
record, then the anchor moves... Page 6 SG: align slides with the other work
items: control plane anchor and dat aplane anchor. SG: use it consistent with
that area. HAC: we can separate - anchoring can be separate or combined. HAC:
needs to allow for legacy systems. SG: in legacy system it is a consolidated
box SG: keep it as a function HAC: we have not separate Marco Liebsch i sML ML:
key of enhanced anchroring is to separate... not to necessarily select an
anchor which is topologically correct anchor HAC: emal list HAC: deployment,
which network, and so on. Dapeng Liu DL: people have different ideas about what
is anchroing DL: anchoring and control plane anchroing DL: maybe in this table
please add definitiion of anchor, and desrbie discuss what is anchroing for you
HAC: only one teleconf we had, so we have to continue SB: problems with
virtualzed EPS, the anchors are not well defined and tightly coupled... SGW,
MME... SB: the enhancemenet is the separation, record, instnatiate dynamically
SB: keep htat consistent not separate awareness.  distribute mobility. SB:
chicken and egg peroble SB: separating  between control element and data
element will allow you to ... HAC: use the email list discuss on DMM. Marco
Liebsch presents Forwarding Path and signalling management Slide: WI as per
charter description Slide: Brief status update

Slide: General objectives of this WI
Slide: Illustration of WI scope
John Kappallimil i sJK
JK: controller is a mobility controller? not a generic separation data-control?
JK: because a daptalapnbe node and an openflow controller
JK: I suppose you mean...
ML: the openflow switches?
JK: thats not in the scope?
ML: openflow is not in scope, we describe a general way
AY: interface between different types of controllers out of scope?
AY: shouldnt it say controller of differenty tpe?
ML: controllers of same type, then we should use synchronization, and the
protocol of sync is ¡§PMIP AY: interface between controllers ois out of sccope
Satoru Matsushima SM: other means of controller is the controller of data
plane, it could be different - the controller is about the mobility x Petrescu>
SM: the controller for data plane is BGP, or openflow controller... ML:
different levels of abstractions you mean? Serge Manning is SM SM: controller i
snot impacting these kinds of transport nodes? SM: is the controller impacting
the transport nodes? dany Moses: it impacts th emobility Xinpeng Wei is XW XW:
two separate entities?  second - is the option node mandatory? Sharon Barkai/
clrificaiton of ADPA, ML: NDPA for certain types of flows AY: definition of
DPA? DPA is Data Plan Anchor AY: traffic flow must traverse the DPA? AY: all
DPAs intercept traffic and forward to mobile AY: you can have multiple DPAs AY:
for flows AY: each DPA intercepts trffic for flow? ML: solution is that? AY:
single DPA per flow?  you could have several SG: dataplane anchor that ... node
of... anchor entry-exit poit Slide: Exemplary deployment case - separated
D-Plane Anchor and Access Node Slide "pmip example" slide " Identified
catefories" Slide "Next Steps" SB: in addition to queries id, please use
publish subscribe SB: when querying smth, use pub-sub John 5JK) JK: big
functions, charging, do you look at how to do that? JK: traffic detection
functions JK: DPI(?) JK: hiybrid way of handling JK: DPA and X should also be
able to handle this SM: for mobility? JK: not necessarily, but whats in the
gateway ML: we should go for that fromm the very beginning ML: offline SG: good
idea to include some generic services SG: draw a line btw provisioning and ...
SG: installing a runtime subscribe Satoru Matsushima SM: slide, controller is
the mobility management slide "next steps" SM: what does it mean in th epicture
the X? SM: is it the borderline, or inside the controller that could be dvicded
by th emobility mgmt side and... the orange border line exists in th emobile
mgmt inside ML: IP tunnel configuration? thats the tunnel SM: on the slide SM:
the slide is "Matchinf a Proy Mobile IP architecture" discussion on this slide,
with respect to the orang eline as an interface placement of the orange line
AY: what are those two pieces? SM: standard like pmip or 3GPP dont have the
separate part of data plane controller SM: we want to try to separate decouple
ML: we shoul dbe making assumptions that there is s plit. ML: control plane is
configured in the dmmm-e SM: when we see the orange border line as interface,
what we try to figure out for control, like BGP SM: but if you say command or
API, then it could be different. ML: commands or attribute specific
descirptions ML: specify the API function, have the atributes described in an
argument list ML: a different way to describe it, w/o a formal description
language. Serge Manning SM: the blue lines are depending of kind of thing: qos,
or other things SM: remember we talk mobility management, dont think of boxes
as a gateway. SM: this is only the mobility management controller, not the
controller of 3GPP John Kaippallmallil JK: these functions are stateful Jouni
Korhonen: next in the agenda is Sri Dapeng Liu comments DL: your WT should sync
with Antony's ML/ the definition of DPA? DL: yes, that should be aligned. Sri
Gundavelli i sSGO presents SG Slide "Scope of the Work Item" Slide "Brief
status update" slide "DMM - Functional Elements" Slide "Functional Architecture
with Home and Access Sistinction" Sharon Barkai SB: sinc eyou do xxx searching
- the function here is the anchor and do you need access node functionality? 
Does the access node functionality there to scale out? SB: better way to scale
out like cluseters? SG: yes, but if you look at anchors are located near tier-1
operators; theyre not always closer to radio network SG: its a flat archi,
people can do it, but start point is this AY: you also miss the client based
MIP AY: not. AY: mobile node should be put in this context as well. SG: nothing
to do it AY: need a colorful box there SG: alright, I will add it SG: should
apply to any protocol architecture slide "Converged Ho,e and Access Control
Plane Functions" Slide back " Functional Architecture with Home and Access
Distinction" ML: slide "Converged Ho,e..." ML: control and data plane
interfaces only between... ML: here we should not differentiate ML: cover all
scenarios, w/o caring about specific planes SG: yes. slide "Home-DPA/Access-DPN
Collocation" slide "Converged Ho,e and Access Data Plane Functions" slide "Next
Steps" John JK JK: slide "Home-dPA..." JK: will the home-dpa move or anchored?
SG: by default the session is anchored SG: is it fixed? no its not fixed,
relocate the session AY: differentiate from the WT2 and 3 discussions on
anchroing, and cpdp? AY : demarcation? SG: WT3 is strictly about interfaces AY:
interface should include this discussion, or this discussion here to drive that
discussion AY: related they are AY: anchroing - same discussion AY: what does
it mean announced anchors SG: from the presentation it is about how to publish
host routes SG: I will follow with Anthony (china accent)/ how this got
involved in the mobilityi management? SG: slide "functional architecture with
Home and Access Distinction" SG: explanatin on slide SG: allocated the session,
session parameters, set up tunnelling, forwarding, activate interfaces
(Marco's) netconf yang SG: tunnel comes up, route comes up, hit the anchor,
gets tunnelled. SG: signalling at this layer, userplane is here. (China
accent): outward interfacE? SG: not outward interface Serge Manning: sessions?
SM: mobility session we have in Mobile IP SM: but here we have per-flow basis
SG: agreed. SM: different set of policies or control stuff Fred Templi presents
"AERO" start on chart number 12 slide "AERO Advanced Topics" chart "AERO
Overviez" Chart "AERO Overviez" Chart "ARO IPv6 ND" Chart "AERO for
intra-network mobility" Chart "AERO Internet-Wide Mobility" Chart "Proxy AERO"
Chart "AERO Capabiloity Discovery" Chart "AERO Control/Forwarding Plane
Separation" Charles Perkins - privacy considerations for DMM slide "Privacy
considerations for DMM" slide "Overview" slide "Need for the draft" slide "DMM
design phase" slide "Known privacy considerations" slide "Some solution
approaches"

slide "Next Steps"
Juan-Carlos Zuniga
JCZ: thanks
JCZ: 802 at IEEE is coordinating with IETF
JCZ: no issues for the momement with the MAC address rdm
JCZ: I am in IAB privsec program, awareness of privacy issues
JCZ: mitigations should we consider ideally now
JCZ: discussion lead to encourage this for all future work in developping
protocols, this is in line JCZ: you will hear more from the statements at IAB
JCZ: in security issues  we should consider with privacy issues CP: in DMM we
consider this SB: in ost models is the anchor as key function SB: possibly to
track you down , makes privacy difficult SB: control and forwarding of the
anchors SB: there is les sinformation known, randmized identifity is a powerful
combination. CP: in the group we discusse Dapeng Liu: be short on next one
Charles Perkins presents MNIDs slide "Overviez" slide "Recent changes" slide
"Issues rised" slide "Next Steps" DP: suggest we can find soemone to review the
doc, and if continue discussion on list, if enough interest we can try to
discuss it whether to adopt this document. Sri Gundavelli presents slide
"multi-homing support for residential gateways" slide "hybrid access
requiremenets" slide "Multipath with Policy-based Routing" sureshk leaves the
room slide "IP Flow Policy" slide "Multipath with Policy Routing"

Jouni Korhonen
JK: thi sis the maintenance part of DM WG
JK: any interest in this group?
Suresh Krishnan
SK: form what I kno, hybrid access is the fixed operators
SK: lma -flawed?
SK: both fixed and wireless acess owned by an operator? the operators I know
have fixed SK: hybrid access augment DSL capacity? there may be ... Carlos
Bernardos CB CB: progress in this WG? CB: need additional discussio, read draft
Behcet Sarikaya BS: this will be discussed this afternoon in thie MIf WG SG:
nothing to do with MIF. JK: lots of hands for who read this drafT? JK: work on
this