Last Modified: 2005-07-22
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# # Monami6 (Mobile Nodes and Multiple Interfaces in IPv6) BoF Minutes # 63th IETF, Paris # Friday 5th, 2005 #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
Nicolas Montavont (NIST, US)
Thierry Ernst (Keio University, Japan)
Many thanks to Minutes takers:
Koojana Kuladinithi (University of Bremen, Germany)
Romain Kuntz (Keio University, Japan)
All presentation materials available on
(site can be accessed in IPv6!)
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# # Opening: Agenda Bashing # 05mins --- Chairs #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
-- Q/A --
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# # Introduction: Objectives of the BOF # 05mins --- Chairs #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
- discuss the set up of a WG
- explain the motivations, need, scenarios, problems
- some of the solutions have been proposed in other WGs, but lack of
interest and time
- interaction with other WGs
Start thinking from a mip6 and nemo point of view
This is not a debate about which approach is best
No plan to discuss technical aspects of load balancing, load sharing, bicasting
No plan to compare mip6/nemo approach compared to e.g. id/locators approach
-- Q/A --
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# # Motivations # Goals and Benefits of Multihoming # draft-ernst-generic-goals-and-benefits-01.txt # 15mins --- Thierry Ernst #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
Draft written with the purpose of explaining scenarios where multiple accesses are needed.
Need to be able to use multiple accesses for permanent/ubiquitous access, redundancy, fault recovery, load sharing/balancing
MN shipped with multiple interfaces, but cannot be used simultaneously Standardized solution needed to ease deployement (need by industry)
-- Q/A --
Q [Marcelo Bagnulo (Marcelo)]
There are other issues in order to fully support benefits described in slides. You are not giving all the tools to address all the issues, you only address one of the issues which is load sharing.
A [Thierry Ernst TE]
Some issues are not solvable here, we need to see how to interact with other WGs. Nicolas will speak about issues in his next presentation.
Q [Chi Ye]
Meaningful and very important work, need a WG to address it. There was also discussion to address some of the issues in SCTP WG.
Thanks for input. But we don't want to debate if we want to bring the solutions at the mobility layer or the transport layer. Let's not discuss which level we should support multi-homing. Our focus is mip6/nemo
Q [Chi Ye ??]
Can be interesting to have references as input, or as experience that could benefit to this work.
Q [Pascal Thubert PT]
What if we build a SCTP tunnel with multiple end-points on top?
A [Nicolas Montavont NM]
Maybe you will not have MIP and SCTP on the same MN
MIP is just for building tunnel, not to decide what the tunnel is made for, could be SCTP tunnel. Make tunnel based on SCTP, MIP will register the tunnel. Single multi-point tunnel using SCTP will be better than 4 ip-ip tunnels on 4 interfaces. Should consider these too.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# # Problem Statement # Analysis of Multihoming in Mobile IPv6 # draft-montavont-mobileip-multihoming-pb-statement-04.txt # 20mins --- Nicolas Montavont #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
Multihomed MIP6 node:
can use several HAs
This draft defines a Taxonamy. End up with 9 scenarios. List issues. Some issues are MIP6-specific, other are generic IPv6 issues. Monami6 is to focus on the MIP6 specific issues.
-- Q/A --
[Hesham Soliman HS]
You say case (1,1,1) is not MH configuration. But MH node is a node with several interfaces because the MN has tunnel interface and physical interface. Technically it is multihomed if you don't specifically refers to physical interfaces.
On a conceptual point of view you are right. This is something we may take into consideration for a better wording in the revised version of this draft.
This was done based on definition of multi-homing, i.e. Multi-homing here means that MN has multiple HoAs or CoAs or both.
Failure Detection? you want to address interface failure immediately, what is difference with "path selection" and "failure detection", those issues should be detailed very well focusing mip6. Not to consider in general, then they are not mip6 specific
We consider "path selection" only from a MN point of view.
Path selection really depends on context, if it's with ISP -> shim6 problem, scope should be more clearly defined.
[Nicolas continues his presentation]
1. bind multiple CoA to a given HoA
2. use HoA as a CoA
3. simultaneous location in home and foreign network
Summary of issues and interaction with other WGs:
MIP6 issues ->can be dealt in MONAMI6
IPv6 issues ->can be done in IPv6/SHIM6/Monami6/DNA
Implementation issues ->monami6?
-- Q/A --
[Charles Parkins CP]
Refering to Hesham's comments on multihoming with single interface, why do you want to restrict only to multiple interfaces here?
We thought we could start with nodes with multiple interfaces, then see if it applies to nodes with a single interface.
Why do u think multiple addresses on one interface is important for MIP multi-homing?
E.g, Use of CoAs on single interface with specific policies. Multiple CoAs and single interface are still useful with some policies.
Need to work again on the problem statement and taxonomy.
[Francis Dupont FD]
Both MIP & NEMO use ipsec. Suggest to interact with Mobike WG.
Monami6 charter says we have to check relations with other WGs
Mobike has multihoming in its charter, but takes a completely different direction: it does not consider the multiple CoAs problem.
Using a HoA as a CoA. MN simultaneously interact with multiple HAs? HA1 - CN? Also posible to have CCoa for HA1
If you use a CoA instead of HoA, the session lifetime might not be long. We have to take those comments as an input.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# # Problem Statement # Analysis of Multihoming in NEMO Basic Support # About issues common to MIP6 and NEMO BS # draft-ietf-nemo-multihoming-issues-03.txt # 10mins --- ChanWah Ng #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
- brief status of NEMO multihoming issues
- classified in several configurations
- 10 issues identified: some are MIP6/NEMO specific issues, some are not
- need to discuss if the NEMO/MIP6 issues could be invetigated in MONAMI6
-- Q/A --
May be a wording problem. I don't see failure detection or path exploration as MIP6 or NEMO issues.
Please look at the draft, in some cases it can be nemo/mip6 issues. In a multihoming situation, there are multiple bi-directional tunnels between the MRs-HAs pairs. Failure detection is about detecting a failed tunnel.
Could you say something to which issues apply to NEMO, and the one that apply to MIP6 ? or does all issues apply to both?
It was presented in NEMO WG.
[ChanWah shows the other slides with he presented in the NEMO WG at 64th IETF]
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# # Current support of multihoming (multiple interfaces, policy settings) # under Linux (MIPL 2.0) and BSD variants (SHISA) # Evaluating Multiple Mobile Routers and Multiple prefixes # in NEMO Basic Support # draft-kuntz-nemo-multihoming-test-02.txt # 10mins --- Romain Kuntz #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
-- Q/A --
[Alexandru Petrescu?? (Alexandru)]
How do you feel about inter-operability when using different policies? How to code policies ?
[Romain Kuntz RK]
In a local machine
It's not good. How do u want to do it?
Dynamic policies could be possible
What are the next steps?
For example exchanging policies between entities
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# # Overview Proposed Charter # 30mins --- Thierry Ernst #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
See the text of the charter discussed during the BOF on http://www.nautilus6.org/ietf/ietf63/monami6-ietf63-bof.html
-- Q/A --
[the slides/charter lists NEMO RFC and MIP6 RFC]
Don't forget the RFC about security
Maybe too ambitious. I would like to see more specific text in the charter. It's more important to speak about the scope of the group. e.g. load balancing is not a specific thing to discuss here.
Charter is quite ambitious. Based on the work done, like to see what charter discusses clearly.
This is a brief overview. We want to show there is a need to do something. See the end of the charter, there are more specific points (see bullet points)
You don't have to say abt studying this problem. it's alreday being discussed & studied.
Let's go back through whole charter
I think a number of issues here are generic IPv6 issues. Some issues are very hard (load balancing...).
We did not put everything here since we have detailed in PB drafts. Do you think the text does not go deeply in the problem?
You should list only the mip6 specific issues instead of generic issues
Generic text should be removed, this is confusing
To enhance performance, application needs policies. This is not really a mip6 problem, exactly ipv6 problems. E.g. Load balancing -> transport problem. This charter is broadly written. Seperate WG to tackle them. Multiple CoAs to HoA -> mip6 WG, acceptable. What is the general, what is mip6 specific issues are not clear enough.
Second para starting with "basically", path repair -> big problem. To be written as only mip6 specific part.
Something to be done with mip6/nemo, considering the deployment, like to recommend for NEMO to do the work with tunnels. MIP6 is busy with IPv6 to IPv4 transition.
Why not mip6? Only nemo? More work to be done. Nemo is rechartering at the end of the year. To solve the problems we should create new WG and not separate work in NEMO WG or MIP6 WG.
What mip6 has to do? We did not feel that issue with very critical earlier considering the deployment. Now it's becoming interesting, makes sense to address the problem. But, where? Same people on different WGs?
[Erik Nordmark (Erik)]
There is also the "multiple tunnels" issue to consider. Multiple tunnels are set up with MIP6 signaling, but the issue is not about mip6/nemo in general. It is more specifically about multiple tunneling: which one is used, maintained etc. NEMO WG ? But BU details should then be co-ordinated in MIP6 WG ? It might make sense to have some requirements on the multiple tunnels (preferences ...)
Multiple CoA and HoAs are very specific to mip6, it's a limitation of mip. So, it's relavant no t only to nemo
[Margaret Wasserman (Margaret)]
Erik's comments are reasonable to me, some are specific to mip6 & nemo, need to organise well where should we do it? Definitively, not everywhere
Interaction between protocols are important
[refers to Erik comments]
Is there really a difference between the MN-HA tunnel and the MN-CN tunnel?
About the MIP6/SHIM6 interaction:
The goal of the shim6 is not to break MIP6, but the SHIM6 can bring some input to MIP6.
Whole mobility probelm in Shim6? highly overlapping problem. Shim6 has decided to work only multi-homing. mip6 should hook to it. Personal thinking, how to optimize mip6 running with shim6. We don't know about those optimisations yet? -> it is too early to speak about what SHIM6 can bring.
The shim6 could help, so if we start to think about it now, we can add input in the SHIM6 design.
don't fragment the work too much, we already have too many mobility-related WGs. Try to build small groups and finish it within short term. Then, monami6 should focus on specific thing. Shim6 should focus on specific thing in short term. Not to work on lots of things for a longer time.
Provide some kind of doc to shim6
I respect your thinking, But ??
Do not agree with the wording. quite overlapping. What should be done, where, not sure to me
[Kurt Lindqvist, multi6 WG Chair, or someone else, don't remember] More and more confusing. Multiple addressing and how to handle it. Completly lost in what you are trying to do.
First to fix how to do it and then to go for mobility. Try to find one place. We don't know details. If we can bring together, better. First produce some docs to identify what to do and where to go?
I don't say we have to wait that shim6 solution is packaged, but now it may be too early. Shim6 is not all done. MIP6 could see how to interact with SHIM6 and NEMO could see how to interact with SHIM6. Do u think should we wait for docs?
When we have a doc, to understand what mobility people think. To finish in a year from now
Where things should end up? Several mobility groups, -> don't understand current standard to better way to go? New group to think about it?
Monami6 is a Sub set of Multi-homing, related to nemo & mip6 only.
We have now 3 dimentions ->v4 & v6, host & mobility, multi-homing. How to rationalise this? It's tricky.
If we discuss this in shim6, people will not understand. mip6 & nemo are well defined. Shim6 and mobility is not clearly defined (???)
Not clear the way charter is written -> "Examine the interaction", "Design goals of multi-homing" If it is mentioned for mip6 & nemo only, it's much clearer, should be specified clearly. Focus should be clear in the text.
Regarding the "Design goals of multi-homing", we don't want to do architecture.
Addessing of multiple CoAs is very concrete.
Any idea when we need this ? There are some solutions.
Now. No time to wait, we need a standard solution.
Car manufacturers for example want IETF RFCs, not drafts.
When is this needed? We do the things right now. Earlier, there was no room to address.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# # Poling the assembly on a number of questions # 20mins --- Chairs #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
See slides, where there are the original questions, new questions, and the score.
Would like to get the opinions of the room:
Q1. Use of simultaneous interfaces is important pb to solve
Yes: almost all in the room
Q2: Is any of the mip6/nemo specific issues important to solve
Q3: Should we work on solutions for these issues
You should ask "should we work on PB staements"
Q3b Should we work on a PB statement?
Q4: How many people are willing to work on the solutions
Yes: 25 -
Q5. Do you think a new WG is justified to work on these issues?
Q6: Do you think we should form a new WG based on the proposed charter?
That's not a question to ask. Charter has to be fixed, you can't work with current charter.
Right. We need to fix charter with comments we had.
So let's change this to Q6b:
Q6b Do you think you clearly understood the charter
[Gabriel Montenegro (GM)]
Should ask like this-> Are you willing to work if charter is modified? We know there are couple of problems in the charter.
What do you mean? Worth to set up WG ? But not to address shim6 interaction,
Not worrying about other things is bit silly to me. Should work with what's going with IETF. What we are going to do within 6 months? 6lowpan was set thinking (????)
6lowpan is currently very narrow. Charter here also has a very narrow objective
If we do this work, with limited scope of multi-homing for nemo & mip6 (multiple CoAs & HAs ) or multihoming and mobility in general (Modify mip6 to interaction with shim6 )? I am not in a position to have a WG to see interaction with shim6 & mobility. I would like to see if people want to do it.
If you need multiple HAs this is where shim6 comes.
[Q7b, question proposed by Margaret]
Shall we charter a group to address NEMO/MIP6 specific issue and standarize some solutions OR shall we charter a more global group to look at the conceptual level in mobility and multihoming
I see 2 problems here: multiple CoA, and Multiple HoA.
[So, question is detailed to:]
Q7b So you want to work on the multiple CoA case?
Do you want to work on the multiple HoA case?
Answer seems indicating not to work with multiple HoAs.
Why do you need multiple CoAs?
For nemo, to have a robust connection, simultaneous use of interfaces.
with RO is also relevant.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# # Milestones, based on charter agreement # Candidate solutions that could be considered and possibly combined # into 1 or several standards # 10mins --- Ryuji Wakikawa #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
+ Mechanism for multiple CoA registrations at HA/CN
for MN, MR, and also deal with RO
+ Mobile IPv6 for Multiple Interfaces (MMI)
+ Home Agent Filtering for Mobile IPv6
filtering on HA side
+ Filters for Mobile IPv6 Bindings (NOMADv6)
+ Flow movement in Mobile IPv6
The last 3 ones are useful to distribute policies amongst entities
-- Q/A --
Why Multiple CoA is useful for redundancy?
What is missing is which path as failed ?
Marcelo has the point. Point is how to identify the failure here
It is easier to manage if the other CoA is already registered and Multiple CoA allow more things.
[Ryuji continues his presentation]
- Multiple CoA registration to get multiple paths between MN and HA/CN
- flow movement/filtering
Would like to standardize those solutions, here or in another WG.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# # SHIM6 - MIP6 Interaction # draft-bagnulo-shim6-mip-00.txt # 10mins --- Marcelo Bagnulo #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
It was also presented in SHIM6 WG
-- Q/A --
I don't see any big problem when I read your draft.
Using HoA on the shim layer is OK.
Might be useful to check what are the advantages to show the CoA to the shim layer.
Isn't mip and shim redundant?
This is the purpose of this draft.
If you are going to do with multiple HoAs problem, shim6 is the right place to work.
Obvious conclusion was to investigate how to work with multiple CoAs???