NETLMM BOF
Monday 1850

Phil Roberts & James Kempf
Moto Labs       DoCoMo Labs USA

Agenda
Agenda Bashing
30 minute disucssion of Margaret's questions
6 drafts, 5 mins per draft
Kent Leung, Cisco, "NetLMM using Porxy Mobile IPv6"
Giaretta, TIM Labs, draft-giaretta-netlmm-protocol-00.txt
Mohan Parthanamury

Latest Charter
http://www.geocities.com/kempf42/netlmm-charter-iesg-revised.txt
At the end we will have a discussion on whether this charter is good.

Margaret's Questions
Chairs added answers that reflect discussion on the list

1. Are there any proposed solutions in this space?
A: yes, see drafts cited on agenda and presentations in second half hour
   There are no wild differences between the proposals.

2. What is the relationship of this proposed work to similar activities in
   IEEE or other standards bodies?
A: AFAWK, there is no work in IEEE on this problem
   WiMax forum and 3GPP have some ongoing work on mobility management in
   advanced cellular networks for which NETLMM could be a candidate solution
   However, neither WiMAx Forum nor 3GPP has formally requested IETF
   to work on this problem.
Thomas: at the last BOF, 3GPP hadn't even decided what their requirements were
        Hasn't WiMax already settled ?
        WiMax forum has decided for MIP4.
KentLeung: WiMAx forum has decided on MIPv6 in phase 1, but there might be scope
           for something else in phase 2.

3. How is this related to CAPWAP and / or the L2 mobility management schemes that
   CAPWAP is based on?
A: CAPWAP runs between a WLAN controller and access points
     Solves problem of control of access points and traff managmenet between access
     points and controller
   NETLMM runs between access routers and a mobility anchor
     Solves problem of localized mobility management within a broader
     domain potentially covering several CAPWAP controllers
     Never sees the access points

4. Charter doesn't mention security requirements and/or have any specific
   deliverables related to security
A: The charter says
     Security will be defined for the protocol based on standard IETF security protocols,
     but should maintain configuration flexibility for varying deployment circumstances
Parviz: this immediately brings to mind different domains
Kempf: once you authenticate in the network, the access router and mobility anchor
       would always be in the same domain.  Otherwise security gets complicated.
KentLeung: in the WiMax forum network working group: this is R3 interface.
           Even there there are 2 partitions.  One is within a network domain (NETLMM)
           the other is inter-administrative domain which is what Parviz is talking
           about.
Kempf: don't think it's a very common use case but if people care we can put it
       in the charter.
Gerardo Giaretta: NETLMM is intra-domain, the inter-domain is MObile IP or something else
Kempf: right, that's the model we've been working with
Hesham: if you look at network-based mobility management protocol, some sort
    of association between access router and anchor point, it is an absolute
    nightmare to work it out.  It's worth mentioning.  It is more scalable to
    do it between the MS and the anchor.
Kempf: I don't see how it would be harder than scaling an SA between two routers.
Hesham: it's the same, it doesn't scale.  You can always set up security between
    any 2 routers.  As numbers increase, it becomes increasingly harder to manage.
    There is nothing on the market that can handle a nationwide deployment.
Jari: security internal on the tunnels doesn't matter so much, what is important
     is how this is connected to AAA and authentication of the MNs.  We talked
     about it on the list.
Kempf: would be good to add to the charter.  We have on the charter how the MN
      identifies itself to the network, we could add something on security.
Parviz: Recently heard from a carrier that they have security issues within
        their own network.  
Kempf: Yeah, we have security issues we're working on them.  Maybe we should
       put something into the charter that says we will work on how this is done 
        securely.

5. Are there any specific drafts that are expected to become WG items?
A: yes, they are
   draft-kempf-netlmm-nohost-ps-00.txt - problem statement
   draft-kempf-netlmm-nohost-req-00.txt - requirements
   Plan is to update drafts based on list discussion and issue WG last call
   as soon as the WG is chartered

Hesham: question that wasn't asked: if we're looking at a BOF, proposal for WG,
        The first question should be: what is the problem?  The problem statement
        I've read many times: it says this is how to solve the problem.  We need
        something that says what the problem is without suggesting a method
        for solving it.  Why can't someone just write the problem?  It's almost
        irrelevant how many proposals are out there, there are a lot of reasons
        why someone would want to change things.
Kempf: You're the only person who has this comment.  We wrote the problem statement.
Hesham: I remember half the room voted on not doing this.
Kempf: we got comments, incorporated them in the charter.  I know there are other
       protocols out there.
Hesham: not the point, regardless of what's out there, there should be a proper
        problem statement of what's missing.
ThomasNarten: what do you mean "what's missing"
Hesham: 10 to 15 years ago, we could say IP telephony needs a solution, would
        be a good problem statement for SIP.
        When a mobile moves, it loses its IP address.  Would be a good problem
        statement for MIP.
Kempf: did you read the requirements?
Hesham: even before that we need the problem statement
Raj: the fact is that at the last IETF in Paris there were many people with questions
Kempf: ok but nobody else said the problem statement was lacking
Raj: what we are saying here is there is a way of doing localized mobility, there
     are ways for the IETF to address it.  What we're saying is there is a better
     way of doing it.  There is no real specific problem: air interface is limited,
     we don't want to signal...
Kempf: the problem statement tries to outline what the problem of network localized
       mobility management.  The requirements and gap analysis 
Raj: you create the problem based on your assumptions.  The fact that you don't
     want the host to do signaling.
Kempf: right, we don't want to do it.
Raj: That's an assumption
Kempf: let me tell you a little story about a mother who was teaching her son
       to cook.  She cut the two ends off the roast.  The kid wanted to know
       why.  She said it was because your grandmother did it.
Thomas Narten: the idea that the handset is not to be involved: yes, it defines
       the solution.  But, it also defines the problem.  If you have a network
       that is controlled by a single administrative entity, control over all
       the devices.  If you have to deal with devices at the edge you need
       to have control over those 
PhilRoberts: the problem statement does constrain the solution, but not in
        an unreasonable way.
Hesham: That would be a good problem statement, but now there is a preference
        for a particular solution.  That's not the way we work here.
PhilRoberts: this argument is off in the weeds.  We've got people that want
        to solve this without touching the mobile.  What is the solution for that?
Hesham: I wanted us to highlight this point.  There's no real problem here.
PhilRoberts: what protocol do I use to solve that problem?
Raj: I hear what you are saying, a lot of people see the need for the solution.
     THere are some people who would be interested in deploying this kind of
     network.
PhilRoberts: we have a huge deployment of client=based Mobile IP.  But, I can't
     use that to solve the porblem.  WHat protocol do I use to solve the problem?
Hesham: we have a client as well that solves this problem.  It's doable.
mic: you say you don't want to involve the mobile
Margaret: we have about 20 minutes left, do people have other opinions?
Alper: it would be useful to understand where that requirement of not touching
       the terminal is coming from.  What will happen to SIP, EAP, etc, not
       just MIPv6
CharlesPerkins: since this WG isn't even formed yet, I'm uncomfortable with
       saying that documents will go to last call and be sent to the IESG
       right away.  We should take some realistic stock of the situation.
Kempf: yeah, we just want people to pay attention.
Mohan: I never saw a mail from Hesham saying that the problem statement 
       is bad.
Margaret: we need to make 3 separate decisions:
       1. Do we want to charter a WG with a charter like this one?
       2. Does that group want to accept certain drafts as WG work items?
       3. Does the WG believe that they're ready to go to the IESG?
  There is no specific time gap between which those have to happen.  Let's
  focus this meeting on the 1st question.
Kempf: absolutely, that's the intent.  We were just trying to answer your
       question.

Kempf: one additional item wanted to add to the charter about looking at
       security of mobile-to-network protocol.
Raise of hands in favor of chartering the working group.  About 40 in favor, 15 opposed.

Protocol Presentations


Gerardo Giaretta
draft-giaretta-netlmm-protocol-00
NETLMM with Distributed Anchor Routers
Network-based LMM protocol that fulfills the requirements of
       draft-kempf-netlmm-nohost-req
Main requirements considered in the design
  Req #2: reduction in handover-related signaling volumt
  Req #4: Efficient use of wireless resources
  Req #5: reduction of signaling and packet overhead in the wired network

The purpose is to use as the basic core network mobility management in 3GPP
Replacement for GTP in GPRS

Main features:
MN keeps the same IP address while moving in the same NETLMM domain
  Different from other proposals: each router owns its own prefixes and advertises
  its own prefixe
Protocol architecture similar to Mobile IPv6

MN is identified by the IP address
   CGAs may be used to avoid address ownership issues
Flexibility in MAP/HAR allocation
  May be in an aggregation router
  May be co-located with Access Routers
    Optimized support for sensors or "users" with minimal movement ability
    AR may span a large area (similar to an MSC/SGSN area)
Multiple MAPs located in a NETLMM Domain
  Needed to have a sclaable solution and load balance among them
In the draft also
  Some considerations on MN-AR interface
  Some ideas about Route Optimization

Picture showing routing of data packets

Margaret: when we asked about forming the WG, 40-odd people said yea, 15 said no
  The comments at the mic seemed to say that they don't like the restriction about
  no handset signaling.  I'm trying to understand the objections.  Some people
  are of the opinion that Mobile IP already solves this problem, that we shouldn't
  have the restriction.
Keith Vanderbing: my feeling is that we should not have the restriction that we
  can't touch the host.
Will Atlantic: at least it should be stated why you want to restrict it in the
  problem statement, otherwise leave it open to multiple implementations.
ThomasNarten: it is useful to understand where the objections are coming from.
  It might be useful to know do people think that there is new work in this space
  that involves touching the handset?  Some people are saying that we have MIP,
  one thing that NETLMM can work on is a client with no MIP.
Kempf: just to clarify about what we mean by not touching the handset: we're not
  talking about movement detection, we're not talking about network attachemnt;
  we are only talking about network mobility.
Alper: confused, if you can put something on the terminal, then we don't have 
  a problem to solve here.  Removing that constraint means we don't need to do
  anything.
Margaret: so the people who objected are thinking that we don't need a new
  solution in this space?
  If there's something we can do to change the charter so that it has more
  consensus, we could do that.  Are there any people who want to form the
  group without the restriction?
Hesham: my objection was that I don't have a problem with defining, for example,
  protocols to do mobility with the routing layer.  As a restriction, it doesn't
  make technical sense.  It makes business sense.
Kempf: suppose I have a handset with HMIP, it has a virus, it starts handing
  out the IP address of the MAP.  Now there is a node in my network that people
  can DoS attack.
Hesham: I understand that some people want this, I don't understand the problem
  statement.
Vijay Deverapalli: you need some kind of extensions to figure out how to get
  an address, the MN to announce itself to the access point.  
Margaret: so you think it is not possible to do what the charter says
VD: it 
GregDaley: I think there is a use case for this, which is looking at Mobility management
   from the network side, it would be nice to give some guidance to people that
   want to do this in the future.  It doesn't have to do away with HMIP.
Margaret: so you think there's room for a different solution.
Raj: kind of think there's the same idea, this is just adding on to the plethora
     of mobility solutions.
Gabriel: think it makes sense, an analogy is IPSec, suddenly get on the WLAN link,
     suddenly if it is required to use it then I can't use it end-to-end.  End-to-end
     still has a place.

Kempf: close the meeting, go to an informal session.