[DMM] Draft meeting minutes

[Jouni <[e-mail]>]

Folks,

Check the draft minutes. And thanks to Peer and Carlos for excellent & detailed minutes. These are combined from those both.

- Jouni

-----------------

DMM WG meeting started at 9:00 am Thursday November 08, 2012. 
WG chair Jouni Korhonen (JK) and Julien Laganier (JL) chaired the meeting.
Minute takers: Peer Azmat Shah and Carlos Bernandos

** Agenda and WG update                   

Jouni discussed the milestones of the DMM WG. He told that in Jan 2013 we have
to submit I-D “Solution requirements” to IESG for consideration as informational
RFC. Also, in March 2013 we have to submit I-D ‘Gap Analysis” to IESG for
consideration as an informational RFC. In March 2012, we also have to evaluate
the need for further work based on the identified Gap Analysis and have to revise
the milestones and/or charter of the group. 

Keorgios Karagiannis (GK): there is no framework draft in the milestones list.
  Would this be included in the gap analysis document?

JK: this is a grey area, the gap analysis should be based on operational
  experience.

Brian Haberman (BH): this has to do with how you design the protocol. Once
  the current milestones are complete, this can be analyzed as part of the
  rechartering process.

Marco Liebsch (ML): it is useful to have design goals, I'm not proposing to
  have a design goals document, but the content should be anchored somewhere,
  maybe in the requirements document.

JK: this is why we have a requirements document. At the end of the meeting we
  will ask which of the four documents would be the baseline for the current
  practices and gap analysis milestone. It does not make sense to keep the four
  documents evolving.

Konstantinos Pentikousis (KP): the gap analysis is kind-of an analytical work.
  The current practices is different. It is better to have two different documents.
  They can be combined for the publication phase at the end, but they are two
  different jobs.

JK: I have a problem of doing a gap analysis based on something you do not have.

KP: you do it based on the specifications and the requirements. The gap analysis
  should have to do with operational aspects and also with what is missing from
  current specs. Specs might not specify something, but leave the freedom to do
  it in a different way. But if something is missing on the current specs, this
  should also be considered.

** draft-ietf-dmm-requirements               

Anthony Chan (AC) discussed the DMM requirements. A suggestion was given by an
audience that unicast and multicast requirements should be done in advance and
we have to keep every thing together and multicast should not be left for later
on.

Luo Wen (LW): Question on Req5, roaming and handover scenarios are different.
  You have a PMIP domain and deploy a DMM domain. Since it is difficult to
  explain here, I'll send an e-mail.

AC: I don't understand the question.

JL: Please, send suggested text you think is missing to the list.

Peer Azmat (PA): do you need information from lower layers?

JK: this is not considered in this group.

GK: you had something on multicast, are you going to discuss it now?

JK: I did not attend the MULTIMOB session but BH has something to comment.

BH: DMM is in the position to now take into consideration multicast. Lets do
  everything together in DMM.

CP: multicast and mobility have been around for a long time and even many people
  say it is impossible to solve the multicast mobility problem. It is important
  to understand the requirements of multicast. This could delay the work on
  unicast DMM.

GK: maybe we should have a requirement that states that the DMM solution should
  have some hooks to multicast, solution specified in such a way that can be
  extended to support multicast.

Behcet Sarikaya (BS): with MULTIMOB co-chair hat on. The requirements should be 
done in DMM WG and the solution should be developed in the MULTIMOB WG.

AC: are you in a position to propose concrete text?

Seil Jeon (SJ): we have some text.

JK: please suggest text to the mailing list.

BH: the requirements should be here in the same single document. People that 
  attended to MULTIMOB WG, please propose text for the DMM requirements
  document.

BS: the current document that has been presented in MULTIMOB WG on DMM is not 
  about requirements, it is about use cases.

Karen Seil (KS): I'd like to see requirements in terms of performance from an
  application point of view. If you are going to do multicast, do it since the
  beginning, because it has security implications.

JK: you do not need to wait for next meeting to say something, please send 
  comments to the mailing list within this month.

Juan-Carlos Zuniga (JCZ): It is good to bring multicast here. I also agree with 
  CP that we should avoid bringing a too strong multicast requirement that 
  jeopardizes or delays the rest of the work. Suggestion is to add a requirement 
  on the "SHOULD" terms.

KP: people should submit requirements for multicast. The other thing we can do 
  is say that whatever solution MULTIMOB does, DMM should support it. I prefer 
  the "outsourcing" solution, leaving the work to the MULTIMOB WG.

Dapeng Liu (DL): the text on the requirements draft comes mainly from the 
  charter and there is no multicast in the charter. If our intention is to do a 
  solution for multicast and unicast, this is going to be hard. If people have 
  strong requirement for multicast it is valid to add it here.


** draft-zuniga-dmm-gap-analysis       

Next presentation was DMM Gap Analysis by Juan Carlos.  He told that the
difference of this draft from version 1 is that Charlie joined as an author.
Comments received from the people on the mailing list have been addressed, 
source address selection mechanism is added and also multihoming in IPv6 is 
included in this draft.  Juan Carlos discussed that different existing mobility 
protocols follow the DMM requirements or not. Then he discussed the next steps 
to address latest comments received on 2nd version of draft.

DL: the title is gap analysis, does it cover also current practices?

JCZ: yes, two clear sections in the document, one covering the current 
  practices, while the other performs the gap analysis.

DL: in my understanding, your document compares existing IP mobility protocols 
  with requirements. We already have done that during the WG formation process. 
  We do not need this at all, as we have already convinced people.

JCZ: what we did in the document is to take a DMM eye on current IP mobility 
  protocols and go forward on how specs could operate in DMM way, so we think we 
  have done what the charter expects.

Yuri Ismailov (YI): we should analyze functions of each of the protocols, and 
  who operates them and how they can collaborate to achieve DMM.

Ahmad Muhanna (AM): this is part of the protocol definition itself.

JK: Yuri, please bring this to the mailing list.

GK: you are missing a framework. Use the requirements, project them on the 
  framework and then analyze how the solutions meet the requirement. It is also 
  useful to include more solutions. The use case on cloud infrastructure should 
  also be included.

ML: I sent some comments to the list. This draft is valuable, follows a 
  bottom-up approach. I also agree with previous comment, we have protocol 
  components and we should compare them with DMM functions. We need bottom-up 
  and also top-down approaches.

JL: related comment. In terms of how current practices are described there. 
  There is one widely deployed mobile network, which is the 3GPP one. This 
  should be added to the analysis (a new column). We need to compare with 
  something that is out there, otherwise the analysis might end up being 
  academic.


** draft-liu-dmm-of-deployment             

The presentation was about the deployment of existing mobility protocols in DMM 
scenarios. Dapeng Liu discussed that what the best current practice of DMM is? 
He added that before deploying existing protocols, first look whether it is 
feasible or not as DMM charter says.  He added that motivation of this practice 
draft is that, there are many proposed solutions for DMM. A lot of discussions 
were made from the audience on the GTP and MobileIP. Julien was of the opinion 
that we should take help from the requirements and gap analysis of GTP to be 
used in the gap analysis for DMM, but all others was of the opposite opinion.  

JL: have you said that there is no deployment of mobility specifications? GTP, 
  PMIPv6 and MIPv4 are deployed. Do not focus only on MIP, consider also GPRS, 
  because it is deployed.

JK: we have deployments of PMIPv6, DSMIP did not make it. We have concrete 
  examples of solutions deployed.

CP: saying that GTP is exaclty like PMIP is like saying a bike is like a bus.

Alex Petrescu (AP): comment on the previos academic aspect. It is hard to do a  
  gap analysis on GTP, because at the IETF we do not have the GTP spec. 
  Regarding the use of MIP, and talking from the perspective of vehicular 
  communications, we do see deployment in this field, with very strong 
  deployment plans.

JL: it was not my intention to say we work on GTP and not on MIP. Just use GTP 
  as another input.

KP: we could also describe what happens on analog communications,  but we do not 
  have any way of affect or influence them. We may have an appendix describing 
  GTP, but we should focus on what we can influence.

KS: Interoperability issues would matter. You might want to identify these, as 
  that would be helpful.

CP: a lot of discussion is going around 3GPP. I wonder if the intention is to do 
  solutions compatible with 3GPP.


** draft-chan-dmm-framework-gap-analysis 

Next, Anthony Chan presented the unified view through reconfiguration of 
existing functions. He identified 3 basic Internet functions and mobility 
functions. He said that we can redistribute the MIP and PMIP functions into DMM 
functions.

Tricci: It is complex to read the draft. If you can simplify it, that would be 
  helpful.


** draft-liebsch-dmm-framework-analysis   

Marco Liebsch presented a set of functional entities that enable DMM use cases 
and IP address continuity. First he discussed the existing MobileIP and DMM 
entities, then he discussed the DD design constraints. He added that these 
design constraints have impact on the DMM solutions. He proposed that we should 
move to a general DMM functionality that can be applied to existing mobility 
protocols, rather than making a complete new DMM solution.  It was commented 
that he does not agree on the statement of the presenter that it is not a new 
gap analysis. He said that presenter has proposed a new framework and gap 
analysis and at this point he is late, as majority of the things have been 
finalized in the gap analysis of the DMM WG.

KP: I do not agree this is not a framework gap analysis. I think it comes it a 
  bit late. Draft is on a very early stage. Overlaps 85% with previous drafts.

ML: the draft is meant to convey the message, hope to be adopted by other draft.

JCZ: when we were doing the analysis we missed some sort-of framework. I do see 
  your draft as complementary. I think it would add value and be complementary.

GK: this is useful, not only for doing the analysis, but also to help people 
  specify solutions.

AM: thanks Marco. Really nice work. I agree with Kostas.

ML: I disagree it overlaps 85% with other drafts.


** draft-seite-dmm-dma           

Pierrick Seite discussed the basic practices of DMM deployment.  The usecase for 
DMM is to distribute the functionality as much as possible closer to MN. He
discussed two different approaches: node centric and network centric.  Many 
questions were asked from the audience and Jouni, WG Chair, told that these 
basic discussions should be made on the mailing list rather than to be discussed 
in the meeting.

Alper Yegin (AY): when do you turn down the tunnel between the ARs (net based 
  solution)? how do you know when to do it?

PS: based on prefix lifetime.

AY: might be long, communications might go longer than prefix lifetime. I do not 
  think this is the best option.

Tricci: when you move to a new AR, how do you get the same address?

Pierrick Seite (PS): this is just PMIPv6.

Tricci: PMIPv6 does not specify that right now. How does the MN keeps the same 
  address?

JL: you keep using the old address, session continuity exists as long as you 
  keep the address anchored at the previous router.

JL: you could use anycast to find the previous anchor.

Carlos J. Bernardos (CJB): I think we are going too much in solution space. 
  Obtaining used addressed by the MN is not a major issue. You can use for 
  example a centralized LMA for control plane, or anycast as mentioned by JL.

Tricci: not an issue, just needs clarification.


** draft-korhonen-dmm-prefix-properties     

Sri Gundavelli presented DMM prefix properties. Followed by a presentation of 
SP-WiFi Service for Retail model. 

Sri Gundavelli (SG): asks the chairs to move this draft forward.

YI: is it in scope adopting this in this group?

JL: lets proceed with the presentation and then we discuss about that.

YI: this option has to be provisioned, who does that? How an application decides 
  which address to use?

SG: that decision is performed based on the policy table, we are just populating 
  the table, we are not telling the host what to do. That is defined in RFC 
  3484.

JL: in addition to policy table there is also an API that allows the application 
  to prefer home vs care-of address. One question I have: you have local 
  breakout, for some traffic you want to have it centraly anchored. Do you 
  expect to have most of the traffic locally broken out? why do not you use 
  source address selection policies provisioned with DHCP?

CP: (missed comment)

SG: not familiar with these solutions, I have to take a look at it.

Pascal Thubert (PT): the scope is not clear. If you want to have local 
  communications, you can use the addressing architecture, for example, using 
  ULAs to use a local printer.

SG: the host should be aware that the local address has no mobility properties, 
  and has to deprecate when moving. Any application with mobility requirements 
  should use a mobility-enabled address.

BH: I'm looking a draft that contains a security bit and a mobility bit. Am I 
  looking at the right draft?

JK: yes.

BH: so you are doing more than mobility capabilities. What was the rationale of 
  associating this with the PIO and not with the RA itself? Are the capabilities 
  associated with the prefix or with the link?

SG: with the PIO.

BH: we have mobility, we have security, which other things you want to 
  advertise? it has an impact on where this draft should be discussed.

SG: if we set up a registry, then new drafts can come and register other uses 
  for capabilities associated with prefixes.

AP: is this only for PMIPv6? when you talk source address selection, this 
  address is only obtained from a prefix in PMIPv6. In DHCP it is not.

SG: also with SLAAC.

AP: if we do source address selection, it sounds strange to put this capability 
  on the prefix. If we were doing prefix address selection, then it would. When 
  you put a single capability on a prefix, you force all the addresses for that 
  address to share the same capability.

SG: if you want properties at address level, then you cannot put it on prefix 
  level.

AY: you might want to look at RFCXXXX (missed the number).

YI: your proposal seemed to be about address selection, but your presentation is 
  about RA options.

SG: maybe title was not good.

YI: if you are talking about address selection, I don't think this work belongs 
  to this WG.


** draft-gundavelli-v6ops-community-wifi-svcs 

SG presents the slides.

JCZ: quick comment. In the IEEE 802 there is this OMNIRAN group discussing very 
  similar issues. Over there, discusssion is more 802 wide. I just wanted to 
  make the group to be aware, there might be some coordination required.


** draft-sarikaya-dmm-cloud-mm        

Bechet Sarikaya presented mobility management protocols for cloud like 
architectures. He discussed the MIPv6 for cloud and told that there are two HA 
planes, HA control plan for data and HA control for Handover. Handover HA 
control plane resides in the cloud. He also discussed PMIPv6 for cloud and 
concluded that PMIPv6 requires fewer changes for DMM as compared to MPIv6 in 
cloud. Sarikaya told that if you want to contribute to this draft then please 
comment on the mailing list.

GK: as I have already mentioned on the mailing list, many mobility functions can 
  be implemented in the cloud. Many EU projects and companies are looking at 
  this. This should be considered as a use case in DMM.

** wrap up

Jouni concluded the meeting with a discussion on the current practices and gap 
analysis and told that we are going to discuss the current practices and gap 
analysis on the mailing list so that we can have an IETF document before the 
next IETF meeting. Final discussion was that whether we should merge the two 
drafts, gap analysis and current practices, or select one before the next 
meeting. 

JK: contribute text for multicast to the requirements. Do not wait until March, 
  do it next week, this month.

JK: the other thing is the gap analysis. We have a couple of potential 
  candidates for a baseline for write up as WG document. We are going to 
  initiate this discussion on the mailing list, and we are going to pick up one, 
  so we have a document before next IETF.

Tricci: question. If two drafts merge into one, is this not allowed?

JL: we are going to ask people what they want to do. Authors of these drafts, 
  please talk during this week.

AP: is it up to the authors to organize however they want?

BH: if the authors want to merge, great, but the WG cannot force them to do it.

KP: I would prefer that we address the comments and we have a more constructive 
  approach. Main point is not to loose information in the process. We will take 
  it offline.

JK: this will be initiated shortly after the meeting.