Folks,
See the attached *draft* notes. Thanks a lot to Wen Luo and Pierrick Seite for
taking excellent & detailed notes.
- Jouni
Combined *DRAFT* notes from Pierrick and Wen Luo
Introduction
----------------------------------------------------------------------
Chair: the meeting will focus on DMM and rechartering discussion
CP: 1H meeting for presentation and rechartering discussion is not enough.
Should schedule another meeting in the week
Jouni: I'll relay to the AD.
Behcet seconds Charlie and stresses that the agenda has been extended to
include other item than distributed mobility
Per-Host Locators for Distributed Mobility Management
-----------------------------------------------------
Marco Liebsch (ML) presents draft-liebsch-mext-dmm-nat-phl
This a new draft. The goal is to provide IP session continuity after mobility
anchor relocation
key features:
- No change in mobility protocols
- address both PMIP and MIP
- Replace tunnel by NATs -> two NATs level
Sri Gundavelli: How the status is created on the NAT?
ML: current mechanism only focuses on the data plane. For the control plane,
different mechanisms could be studied. We can have a database maintaining the
mapping, similar to LISP. The issue on dynamic update of the binding. We have
thought about but not yet write down. It depends on whether you consider the
ingress router and NAT on the pMAG.
SG: can we assume a signalling protocol between those entity?
ML: Yes, we can assume
SG: so, it is not a pure database signalling but state creation
ML: yes
Pete McCan: on the forwarding plane, we can do NAT, tunnel, or even routing?
ML: the advantage we see here, is that we can use routing reusing the existing
routing plane. You don't need per host state on all these router. You just need
state on the Ingress Router (IR).
PMC: right. The point is that the solution doesn't look very distributes, it
looks like an additional layer of hierarchy. The architecture between the
Ingress Router and the pMA may be more distributed.
ML: I don't think it is an additional hierarchy in mobility anchors. It's
router which needs Per-host state, true. But it needs to state only after
anchor relocation, which means: on the pMA the identifier is routable, it don't
need to state there. It's only when the MN moves that you need to create a
state on the Ingress Router.
Approaches to Distributed mobility management using Mobile IPv6 and its
extensions
----------------------------------------------------------------------------------
Raj Patil presents draft-patil-mext-dmm-approaches
Already presented during previous meeting
Scope: the draft discusses solutions how deploy DMM
Raj reminds "well-known" issues of centralize architectures
Raj argues that we can take existing protocols and their extensions (HMIP,
PMIP) we don't need new protocols but itÃs worth providing a BCP.
No question/comment
PMIP Based Distributed Mobility Management Approach
---------------------------------------------------
Wen Luo (WL) presents draft-liu-dmm-pmip-based-approach
Solution in few words:
- MN to CN comm. via MAG to MAG direct path.
- Traffic anchored at the MAG close to the CN
- LMA used only as a locator
Charles Perkins: how can the cn distinguish between the pMAG and a malicious
node sending out this update?
WL: do you mean there is a security issue?
CP: Yes
WL: CN and MN are in the same PMIP domain.
SG: How does the MN know the MAG-CN?.
WG: get it from the LMA.
SG: so, how does the LMA know?
WL: both the MN and CN register to the LMA as PMIP does, they are in the same
PMIP domain
SG: But the CN has no security relation with the LMA
WL: if the CN register to the LMA, the LMA knows the CN-CoA.
SG: itÃs true if both MNs are anchored at same LMA but what if the CN has no
relation to the LMA?
WL: you mean using two different LMA?
SG: not only, the CN may be a fixed node, so not anchored at the LMA.
WL: ok, I can consider it further
Marco Liebsch (ML): already commented in last IETF, but if youÃre considering
that both the MN and CN are registered to the same LMA, what are the difference
with LR designed in netext WG?
WL: we have some difference in handover considerations between this solution
and the one in netext.
ML: you could consider direct tunnel to CN which is not registered to the PMIP
domain. In this case, CN is a generic IPv6 node and you establish a direct
route to it. ThatÃs something new.
WL: In this case the MAG of the MN does not know the CoA of the CN. So, it
operates as the PMIP does.
ML: ok, some addition
Bruno: If CN and MN are in same LMA, HMIP has same benefits. So I donÃt see
any reason to not use HMIP.
WL: HMIP is complicated and hard to deploy
Use of Proxy Mbile IPv6 for Distributed Mobility Control
--------------------------------------------------------
Ji-In Kim (JIK) presents draft-sjkoh-mext-pmip-dmc
Solution in two words:
- The MN and the CN are in the same PMIP domain -> communication between two MNs
- the initiator gets location of its correspondent up to a centralized location
database (partial distribution) or floods the network to query all MAGs (fully
distributed solution)
- new messages to achieve this: PBQ/PBA
- then inter-MAG tunnelling
- Address both partial and full DMM approaches
SG: How does the nMAG knows the LMA for the MN? In other words, how do you know
where to send PBQ?
JK (clarifying the question for JIK): here, you cannot make an assumption that
that CN and the MN are in same PMIP domain: the CN can be generic IPv6 node,
e.g. a node in the Internet. In this case, how does it work?
SG: yes, how do you enforce this assumption?
JIK: the LMA is the anchor point, so the CN sends a packet where the
destination home address is the LMA, so,...
SG: no, the destination address belongs to one of the LMA prefixes. But how do
you know the LMA which has allocated that prefix: LMA is hosting P1, P2, P3
prefixes. When the CN sends a packet to P1::/, how do you know the LMA
corresponding to that prefix.
JIK:...
JK: You should discuss offline or in the ML
Dapeng Liu: for the Full distributed approach. How do you do the authentication
if there is no LMA there.
JIK: the SD-PMIP [note: fully distributed] is the worst case. So, the MAG
replies to the CN, so,...
DP: do you mean that the MAG does the authentication of the MN?
JIK: mhhh...
JK: ok, letÃs continue discuss on the ML or offline
Re-chartering discussion
------------------------
Introduction:
The discussion is based on AD's email (sent on the October, 28th), based on a
proposal from a group of motivated people.
Jouni reminds that a short sentence on distributed mobility management already
exist in the charter.
We already had discussed on the ML (Jouni posted a summary). The discussion has
been motivated by 3GPP architecture and evolution. ItÃs a good thing but
protocol designed here must not address only 3GPP needs.
Reusing existing mobility protocol should be the priority. Non anchored
solution are also in the scope.
DMM should not break anything.
Focus on IPv6 based solution, but we'll not ignore IPv4 .
Summarizing the discussion, it is suggested a 4 steps process:
1. address problem statement and requirement.
2. gap analysis with centralized approaches.
3. BCP reusing current protocols and existing extensions.
4. specify new extensions if needed.
Open discussion:
CP: [Charlie says again that 1H long meeting is not enough to discuss such
issues. According to Charlie, posting the claim for rechartering only 2 or 2
weeks before the IETF does not give enough time for discussion.]
Shorten the WG to DMM may be problematic. MEXT is the right place to address
improvement of Mobile IP and, considering what 4G networks should do, itÃs
clear that Mobile IP has some design inadequacies that need to be remedied.
[Charlie made a proposal to AD for that]. It seems that there are enough people
to support effort on other issues than DMM, at least to identify remaining
issues: Charlie thinks that we should not short the WG down.
Charlie suggests to try to identify other work items before next IETF.
Jari Arkko (JA): We do not have enough time to reach a conclusion during this
meeting.
Jari clarifies that it is not shorting down MEXT, but, here it is to focus on
one topic. Jari has nothing against adding new things in the charter IF there
is significant interest. But we need to see interest and demonstrated interest
weÃve not
seen that for everything in the past.
CP: appreciate what Jari said. Because we have not enough time to discuss
during IETF 82 meeting, Charlie suggests to have a ML discussion to see if
there is people to support effort on redesign of (P)MIPv6. Then make a decision
on IETF 83.
JA: discuss what people want to do (and if there is energy on the WG to work
on) is useful now, we'll focus on that.
Raj Patil: agree on continue enhanced mobility protocol as Charlie said. There
are extensions that can be still be specified. Think there are enough people
that are able to support the effort.
JA: Jari reminds that there is not so much remaining items in the charter: AD's
sponsored security document is going to the IESG. Other documents in the
security space would be too. Jari is not in favour to include vague items like
"improving protocols". If people have good, and precise, ideas and energy to
work on, there is no objection to include these items in the charter.
Anthony Chan: [going back to the DMM discussion] Jouni's slides summarize too
much previous discussion. Anthony says that large number of people discussed
the DMM stuff on an ad-hoc mailing list (called DMM); they have issued couple
of documents (including the current charter proposal). Also, I-D exists on
problem statement and use-cases. Anthony suggests to get this as an input to
going further. Anthony stresses the need for a problem statement and
requirement and volunteers to continue to work on.
JK: it's an open process; everybody is encouraged to provide inputs and inject
their own ideas.
JA: Clearly we take off-list work. Recharter text is based on that work. The
question is: do you have opinion about the charter here? Do you want a tiny
version? What is it the charter want to say?
HC: stresses the need to have a clear understanding on what the issues are. The
evolution of network architecture gives the framework and may impact mobility
design. For example, introduction of CDN. Also, there no clear definition of
distributed mobility. Thus, need a document which clearly defines the problem.
Hannes: In previous WG session there were a discussion on the lack of
deployment for Mobile IP. Last week, Charlie gave a presentation on a workshop.
Encourage people to share their views/thoughts, on the ML, to get a better
understanding on the problems and what the issues are.
PMC: some of these issues, especially, when we talk about a MN using a CoA
without tunnelling are getting into details inside some of the mobile operating
systems. Pete suggest either people from the IETF or outside the IETF can get
involved in the discussion. Involve either some of the major operating systems,
vendors,... So we could develop a system architecture at the same time we
develop protocols for the network side. We could involved outside entities in a
way we did not in the past.
JK: yes. Good input.
Behcet Sarikaya (BS): [Behcet seconds Charlie]. I [Behcet] don't like
non-anchored solutions.
JK: Is there a reason for that?
BS: Yes I'll explain. [Behcet likes the slides] Also, I'd like to see problem
statement and requirements to really understand motivation for CP/DP
separation, distribution,... Behcet suggest to start focusing on MIP. Then, if
there is interest, consider PMIP (or whatever) as well.
ML: fully agree that this work should not be specific to 3GPP architecture but
3GPP has no problem on using MIP/PMIP. The problem is on the deployment. But
looking at the proposal we have on the table so far to address distributed
mobility, some of them tries to address different aspects of the problem. So,
Marco fully agrees we should work on a joint view of the problem, then agree on
some design goals/requirements. We may agree on mechanisms which may easily
apply to MIP/PMIP. Or, we may reach the conclusion we need support of other
protocols, like Diameter, or Radius. Modify these protocols is Out of the WG
scope but we should cooperate with corresponding WG. First step is problem
statement getting design goals and requirements, then define how to touch
MIP/PMIP.
DL: Dapeng responds to Behcet: we should not preclude PMIP or non-anchored
solutions at this step, we should consider both possibilities.
SG: It is fundamental to not define new signalling semantics. Anything we do
must be based on MIP/PMIP protocols semantic. This should be the based criteria.
Ryuji Wakikawa (RW): comment on the second bullet of (slide?). It's not clear.
Do people want to define one protocol covering HA/LMA distribution? Because, we
use to say "Anchor point". Anchor point may be HA/LMA/MAG, so there may be
different solutions. Sentence stating optimal tunnel between mobility anchors:
this is pretty much PMIP. Charter is vague, maybe you assume some solution.
Ryuji suggests to revise the charter to clearly identify what we want to work
on.
JK: Jouni has the same feeling but reminds that the charter has still not
converge to what we want to have.
CP: Charlie suggest to consider the extreme cases: 1) completely hierarchical
solution 2) completely non-anchored solution. We can make lot of progress just
considering extreme cases and figure out how it works.
HC: want to clarify 2nd bullet: many solutions for deployments of anchors, the
fundamental is geographical distribution which can be more or less flatten,
which may lead to lot of anchors. It is up to the deployment. The issue is to
make them work together.
CP: Of course there are many possibilities. But it impacts the solution space
when you decide the level of distribution. MN may use different anchors at the
same time, so inducing lot of signalling. So, lot of anchors and lot of
signalling.
PMC: Pete advocates to relax the requirement of maintaining the same IP address
for the MN during the session (even when PoA handover).
JK: yes, it is what we have today.
JA: It is hard to draw for a conclusion, but there are few things it can be
asked to the room; on what the charter should include: four things if you like
to see these in the charter or not.
Q1: First one will be this narrow scope that only operational document that
describing how to use current protocols in a distributed fashion, no extensions.
Q2: Second one is more or less like this on the screen now which is basically
all of the above and also possibly some extensions related to DMM.
Q3: The third question is we should include both proxy and client mobility, and
Q4: fourth thing is if you want more open ended MIPv6 improvement.
JCZ: do we need support of the OS and manufacturers support? Refer to long
discussion within netext on logical interface
JA: everything we do need support from manufactures.
Q1: narrow definition of the charter focusing on operational considerations or
wider scope including protocol extensions
Consensus on wider 'Q2' scope
Q3: include both Client Based and Network Based mobility solutions in this work.
Consensus on including both Client an Network.
ML: says it would be more natural to start with narrow scope, then move to
wider scope if necessary
JA: Jari agrees and says that the charter should reflect this.
Q4: enhance deployability of MIP.
JA: it is unclear on Enhance deployability of MIP; it might be interested but
we need more details on what it can be proposed
JK: we'll continue discussion on the mailing list and work on the charter text.
Clear concensus for Q2 & Q3.
Additional document presentations
---------------------------------
No time to present
o Distributed Mobility Management Protocol with Multicast
Support (draft-sarikaya-mext-multicastdmm) - Behcet Sarikaya (Huawei)
o global HAHA (draft-kuntz-dmm-summary-01) - Ryuji Wakikawa (Toyota)
o Negotiation of security protocol for Mobile IPv6 operation
(draft-patil-mext-sec-negotiate-03) - Bruno Faria
_______________________________________________
MEXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mext
