Minutes for DMM at IETF-92
minutes-92-dmm-1

DMM Session Notes

Tuesday:

working team1: Exposing mobility state, Alper

Mobility Exposure and Selection 

Presentation summary: DMM API between application and mobile node: Extensions
to RFC 5014 – 3 distinct flags added (fixed, sustained, nomadic)
yegin-dmm-ondemand-mobility
- 3 new flags, to convey between app and IP stack.  Liu-dmm-mobility-api
- Defines 2 flags, could not understand semantics on call. But it is
  missing 1 flag and dyn config of IP address

Request to adopt this as WG draft.

Comments:

Dapeng: fundamental question is what is the relation of this to dmm?
  Does it solve the problem in dmm charter?  
Alper: going back to a year ago; on demand use of mobility.  
Dapeng: some extensions proposed, but how is it used?
Alper: draft describes use – application and stack behavior.  
Dapeng: don’t mention what is the problem solved in dmm scope.  
Alper: this was gone over in previous IETF.  
Dapeng: there is a gap between charter and solution
Alper: what is it?  
Dapeng: 3 flags added – but there is not related to dmm

Sri: this is an enabler for avoiding host routes, tunneling, it is for smaller
  cells.  The idea is to enable the client to enable obtaining new IP address –
  multiple IP addr, and client intelligently switches (awareness).  
Dapeng: agree with the statements, but how does the flags help?  
Alper: flags help applications indicate intention to stack 
Alex: how does this happen in network
Alper: another draft indicates how it happens in network.  
Danny: will be presented on Thursday.

Jouni: this is one enabler – application to stack part. This is independent of
  other network signaling – IKE, DHCP etc. CoA, HoA in MIP etc.  In DMM some
  addresses are OK and need to know what kind of addr is being requested.

Danny: is it now clear?
Dapeng: not fully
Danny: this is a part solution. Some apps need sustained addr, and others
  don’t. This draft identifies different services and lets the application
  communicate to stack.  Other draft explains the stack to network part.  
Dapeng: agree in general, but not specifics. We need to also solve dynamic
  anchor problem
Danny: it is not expected to solve dynamic anchor problem.

Alex: Two comments: One - IP addr autoconfig – don’t see a parallel elsewhere
  in IETF
Alper: RFC 5014 already defines 2 options 
Alex: doesn’t this satisfy the requirements?  
Jouni: prefix coloring work needed 
Alper: prefix coloring comes as network-part solution 
Alex: skeptical. If dhcp wg gives type for addr, then this API makes sense.
  They should progress together – can WG adoption be made in that case?  
Jouni: more presentations on Thur.
Jouni: during charter, there was agreement for the need of such protocol
  as prefix color, etc. This is part of solution.
Alper: all pieces present is not needed for WG adoption.

Alex: 5014 options not implemented in Linux.

Alex (comment 2) – do apps run on mobile node?
Alper: could be on router.
Alex: cannot be on router. This needs to be stated in draft.

Sri: we do run applications on mobile routers.

Marco: apps which send request and expect an IP address config in response –
  how can application decide?  '
Alper: application can decide – e.g., chat, etc.
  can indicate to stack.

Xinpeng: will the app developer be confused - because they do not care about
network address – ie. Will they use the options?
Alper: apps that want
efficient networking will adopt.
Xinpeng: is the prefix defined – should it be defined here in dmm, or..
Alper: considered here first, and then taken to different normative
  WG (dhc, 6man).

Jouni: the working teams are open and can be joined, reviewed by anyone.  
Alex: agree that it is open --- on the other hand, it is in IETF meetings
  that decisions are made and should not hold that against one who did not
  participate.




working team2: Enhanced anchoring, Anthony/25min

Presentation summary: Enhanced Mobility Anchors work team report Enhanced
anchors for moving networks AAA arch for DMM Moving IP address Allocation of IP
address to mobile mode – HoA, HNP etc Functions of an anchor Anchor selection
and switching Anchoring IP address

Comments:

Sri: is prefix delegation initiated by client?  
Anthony: not by the client. Its from one router to another.  
Sri: what protocol is used?  
Anthony: prefix delegation protocol, or SDN, control plane.  Anchoring session
  (with and without IP address change) Anchoring of the session in addition 
  to the IP address implies move of session anchor 

Sri: what is a session anchor? Are you routing an IP flow through one path, and
  session at another point?  
Anthony: you try to make the session go through the anchor.  
Sri: how is the forwarding plane able to steer the IP flow through one
  path, and others to another path? Some kind of stitching?  
Anthony: session anchor moves independent of IP.

Marco:  Mobile node has 2 IP sessions, one of which is on AR2.  Is IP1
  deprecated?  
Anthony: (referring to slide 11) - anchoring only the IP address on
  AR (right side).

Sri: not following this. Session re-anchoring – how we move the subscriber
  session to another node is not related.  
Anthony: we do not have a definition of mobility anchor for session, and
  that part is not enough.

Sri: what is a session A: it is a flow Sri: seems like a mixup of terms.

Kent: clarify session – seems to be that IP session can move independent of IP
  address 
Anthony: [walk through slides again] 
Kent: transport of flow to that anchor, topology, etc., needs to be clarified 
Kent: session is not at the flow level – can do tunneling. Cannot route at
  flow level.

Sri: route optimization is different. CoA and HoA are present in the headers
  and that’s how it is handled.  
Anthony: this is just at high level, it is just an analogy. Trying to harmonize
  the different proposals

Sri: IP address and sessions are on different nodes – that’s not clear.

Jouni: there is a problem with terminology because people cannot flow – need
  clarity on the terms.  Describe with existing technology so that it is not
  difficult to follow.  Show what the mechanisms are to move between the nodes.

Dapeng: is the draft a consensus of the team?  
A: there are comments from team, but open to listen to more comments.






Thursday:

working team3: Forwarding path and signaling Management, Macro

Presentation Summary: Functional decomposition & FPSM is the scope.  Protocol
and mechanisms that work across stds.  FPC client and FPC agent use common
protocol semantics for policy config, queries and notifications.  Generic
policies and forwarding rules are defined – logical port, grouping concepts.
Next step is to adopt information/ data model.

Comments:

Fred: wrt PMIPv6 as example – could AERO be another one of them?
Marco: it is orthogonal. AERO protocol can use it too.

Carlos: in favor of adopting 
Georgios: in favor of adopting

John: what is the relationship to Forces, OF?  
Marco: focus here is on mobility and semantics needed. Next step would
  be to apply to concrete implementation like OF.

Xinpeng: why is QoS included in the attributes? Isn’t this about mobility
  management.  
Marco: there are extensions for QOS and mobility management as in PMIPv6 QoS.

Jouni (Chair): is this mature enough to be adopted as WG doc?

In Favor? [many] Should wait and see for more content. [1]



working team4: Distributed mobility management deployment models and scenarios,
Sri

Presentation summary: CP-DP separation.  Aggregation of control plane can
provide elastic scaling.  Selection of GW based on session requirements (e.g.,
DPI for some sessions) Mapping of DMM functions including aspects of splitting
functions into CP/DP, mapping to different architectures.  It provides the
ability to pick a data plane anchor (DPA) on demand.  Security model here
includes – IPSec, IKEv2.  Deployment models explained.

Comments: 

Danny: CP is centralized, DP distributed. One control entity and many
  DP entities?  
Sri: if the question is - do we decompose the control plane, then
  consider that we could have VMs, etc.  
Danny: should it be part of this doc?
Sri: this can be part of informational text.

Dapeng: is there session continuity support for anchor relocation?  
Sri: yes.

Hui: can you do chaining for DPA?  
Sri: could have root anchor doing one function, and then [interrupted ...] 
Hui: IP acceleratio, DPI, etc. on data path is the question 
Sri: I see - service function chaining – not captured yet..  
Hui: these functions are inside a GW for example 
Sri: yes. Gi-LAN or similar functions in the data plane needs to be told
  where to steer the traffic.

Anthony: why distinguish between node and anchor? (and not have anchor-anchor)
Sri: in today’s network, session is anchored at LMA at home, while not at MAG.
Anthony: so its where IP is anchored.  
Sri: right.

Marco: data plane functions may be chained, and this needs to be considered.
Sri: yes.



draft-matsushima-stateless-uplane-vepc-04  Satoru

Presentation summary: changes in the new revision - Forwarding Policy
Configuration Protocol as a means to expose Control-plane states from mobility
management to BGP speaker.  Next steps – outline how this is applied to work
item 3, 4.

Comments: 

Dapeng: is this aligned with arch as Sri presented?  
Satoru: not sure, but this work was started before and trying to align. 

Sri: it is aligned, but we should ask for more comments

Fred: the presentation referred to BGP work from Boeing. Will you refer to RFC
  6179 for DMM also?  
Satoru: it would be different purpose vs. the use of BGP here (as vertical
  protocol).

Marco: this fits into work item#4. It is very concrete implementation.

Jouni: not ready to ask the question of adoption call today, but would like to
  see more people work on this.
Jouni: who is ready to work on this draft? [many]
Jouni: who thinks this does not fit?  [no one]

Alex: is this implemented in some platform for research/students, or is it in a
  proprietary platform?
Satoru: different parts in the solution – EPC, BGP, etc. The extension of BGP
  is available, but EPC is not.  
Alex: EPC is not something implemented at universities.



draft-moses-dmm-dhcp-ondemand-mobility-00 Danny

Presentation summary: address types – how to extend IPv6 client to convey to
the application what the client is requesting IA address option carrying source
IP.  New option: IP continuity service option to carry the type of the IP
address.

This work will need to be taken to DHC group after agreement in dmm.

Comments: 

Fred: as a mechanism, this is fine. Fixed addr, nomadic addresses are
  returned – how is it assigned to the right interface?  
Danny: stack needs to keep track.  
Fred: how does the network know which address is nomadic/static etc.  
Danny: network does not care.  When the client moves to new location,
  nomadic addresses cease to exist. Network does not nave to support 
  moving it, tunneling etc.

Fred: this is a simple extension, but there is a lot of detail underneath
  that is not shown.

Sri: a comment on how apps make distinction of address – there will be an
  impact to RFC3484, right?

Marco: puts assumptions on DHCP and that puts some impact on anchor selection
Danny: yes.




[Draft Yegin adoption call]

Jouni (Chair): is this a good basis for first draft for the application –
  stack.

In favor: [many] Oppose: 3

Jouni: rough consensus…

Brian (AD): who is willing to put in work on the doc?  [Response is about the
  same group as those that support]

Chair (Dapeng): please make clarifications to document based on questions on
  the mailing list.



draft-sijeon-dmm-use-cases-api-source-00.txt Alper

Summary: Further extensions to the dmm api extns draft Flag for new application
to indicate preference for new address

Comments: 

Danny: which application would prefer to be anchored to a far away
  anchor?  
Alper: [interrupted ..]

Danny: it asks the stack to ask for new addresses – how does the stack know,
  and how will this not be abused?

Fred: if the sustained address is always close, then would this be needed?
Alper: these need to be considered

Jouni: can this be added into draft-yegin?  
Alper: yes.



draft-yan-dmm-hnprenum-00.txt Zhiwei

HNP renumbering based on RFC 7077

Comments:

Jouni: is this part of maintenance part of dmm (PMIP related)?
Presenter: yes

Sri: technically makes sense. RFC 7077 makes sense..

Alex: will the renumbering imply breaking session continuity?  Presenter:
  session would be restarted

Jouni (Chair): please comment on the mailing list in support or against, and
  bring up the issues.



draft-templin-aerolink Fred

presentation – no comments.



Discussions:

Charlie: with regard to mobile node id draft – the intention is to request for
  adoption.  
Jouni: this is related to the maintenance part of this group.

Alex: agree with most points, so an adoption would make sense if it is in
charter. 

Alex: Is this open for suggesting new identifiers?  
Chair: yes Alex: developing new id for car.  
Chair: bring it in to the working group.


{next discussion}

Sri: Pierrick has a document on hybrid access that needs
  follow up.  
Chair: don’t recall any discussion on thread.