MIP4 WG Minutes (Monday, August 1, 2005, 1815-1945)
MIP4 WG Minutes (Monday, August 1, 2005, 1815-1945)
Minute takers: George Tsirtsis
There were no comments on the agenda.
- NETLMM Monday 0900 - 1000
- MONAMI6 Friday 0900 - 1130
http://mip4.org/charter/mip4-charter-2005-07-13
A new charter proposal has been submitted. I'ts available at the URL given.
However, if any new workitems are proposed and accepted by the WG during this
meeting, this will have to be updated.
The following work items are part of the proposed charter update:
- Radius Attributes
- Generic Strings
- FMIPv4
draft-bharatia-mip4-gen-ext-00.txt
Slides: http://mip4.org/ietf63/mip4-gen-ext.pdf
This draft defines a Mobile IP extension for configuration options, which should be
used by any Mobile IP entity to exchange information of the network entities like
DNS server address, previous Foreign Agent (FA) address etc.
Comments:
-
Charlie:
-
Is this for host configuration from the HA?
-
Jayshree:
-
3GPP is using L2 mechanisms to carry info...would be nice to do it over MIP.
But this is only one option. This can be used for other things.
-
Kent:
-
the L2 mechanisms probably provide local info anyway....we need home info too.
draft-bharatia-mip4-gen-ext-00.txt
draft-leung-mip4-host-config-vse-00.txt
Discussion:
-
Henrik:
-
Why not just carry the DHCP option format instead of redefining?
-
Jayshree:
-
Yes
-
Someone:
-
Options should be minimal, the rest should be done over DHCP
-
Henrik:
-
Should we adopt this or Kent's draft or merge them?
-
Kent:
-
The Kent draft was proposed 2 years ago with no success. 3GPP2 defined this
with VSEs. Cisco also defined VSEs defined as informational. This new draft is
good as a way forward for standards track doc. We should not eliminate existing
implementations though so the info RFC should also progress.
-
George:
-
Kents draft is in IESG hands and independent. This should go ahead by itself.
-
Henrik:
-
Should we take this on?. 6 say yes. 5 say they will work on it. 0 say it should
not be taken on. It will be taken on.
-
Conclusion:
-
This will be proposed as a new work item in the updated charter.
draft-devarapalli-mip4-mobike-connectivity-00.txt
Slides: http://mip4.org/ietf63/mip4-mobike-connectivity.pdf
This draft presents an alternative to using dual-MIP (as described in
draft-ietf-mip4-vpn-problem-solution-01) for combined MIPv4 and IPsec deployment,
when the VPN gateway supports MOBIKE extensions.
Comments:
-
Someone:
-
I like the idea. You are using the VPN only when external. OK in enterprise but
maybe not always?
-
Vijay:
-
Some enterprises want you to use VPN all the time which is OK, this can be used
in this case
-
Kent:
-
Question. Does this support FA mode when outside? From a network that has FAs?
-
Vijay:
-
No this mode is not supported
-
Henrik:
-
This and the double MIP solution solve the same problem in different ways, with
no new protocols, just describe how to use existing tools.
-
Kent:
-
MOBIKE is between MN and HA...if there is an FA MOBIKE can not be used.
-
Someone:
-
This is not design for fast handoffs
-
Vijay:
-
Yes, you can probably combine it with fast handoff mechs
-
Henrik:
-
Realize that although MOBIKE provides mobility it is not designed for fast
handoffs.
-
Discussion:
-
Both the dual MIP and MIP/MOBIKE solutions require cooperation between the two
Mobility clients.
-
Discussion:
-
Do we need both solutions? Henrik/Vijay say yes, Gopal says no. lets take it
offline... Discussion continues for a little while more, but Gopal does not
have the same viewpoint as others.
-
Henrik:
-
Should we adopt this? As part of the already described VPN problem statement?
Or should we merge the two solution in one doc to fully describe the problem
and solutions?
-
Gopal:
-
Lets not try the dualMIP solution for this.
-
Vijay:
-
I think dualMIP is stable. This new one is simple 10pg long. We do not need to
merge. Lets make them consistent/clean-up.
-
Henrik:
-
OK, no merging. So should we adopt? 12-15 yes. 7 say they will work on it. OK
it will be added. 0 say no.
-
Hesham:
-
We should no really have multiple solutions...although I do not have any
problem with this particular solution.
-
Henrik.
-
I agree in general, but the two solutions are separate.
-
Hesham:
-
but what should the MN implement?
Henrik: Yes the default should be addressed.
-
Gopal: Why not do this in MOBIKE. We now going to have two
-
solutions...back and forth with Henrik...take it offline.
-
Conclusion:
-
There is rough consensus in the working group for taking this on, with some
dissent about describing 2 (complementary) solutions. This will be proposed as a
new work item in the updated charter.
draft-jin-mip4-ha-switch-00.txt
Slides: http://mip4.org/ietf63/mip4-ha-switch.pdf
This document specifies a new MIP4 control message that can be used between a home
agent and mobile node to signal a mobile node that it should acquire a new home
agent.
-
Discussion:
-
Applicability. Take down could be done by rejecting requests or use of
redundant HA.
-
Kent:
-
Operationally it might be useful for various reasons like errors or change in
billing etc.
-
Henrik:
-
Yes applicability is not defined enough. The general capability of
notification message may be useful.
-
Henrik:
-
Should we take this specific draft on? 6 say yes, 2-3 say they will work on
it. 1 says no
-
Henrik:
-
Should we take on the general idea? 20 say yes, 2-3 say they will work, 0 say
no
-
Henrik:
-
OK we go with the general idea.
-
Conclusion:
-
A new draft is needed, describing a general notification message. The WG will
consider adoption of such a draft when it is available.
draft-ogashiwa-mip4-bid-extension-00.txt
Slides: http://mip4.org/ietf63/mip4-bid-extension.pdf
This document specifies a new extension which carries a care-of address binding
identifier, for the purpose of being able to couple tear-down and set-up of
bindings when simultaneous bindings are used.
Discussion:
This is dealing with complex issues. Some think that it enables complicated
things to happen but we do not have to get into all of that. Some think that it
does not do anything without defining how you set up the routing tables
-
Henrik:
-
We tried to define how routing tables are set-up before but the WG and Chairs
did not want to do this. You can also do this with a dereg followed by a reg.
If not then you probably have other assumptions. Maybe we need to have a bof on
multihomed MIP4...this is too immature.
-
Hesham:
-
The chairs now are ok (after many year) to work on multihoming and MIP4?
>laughs<
-
Henrik:
-
yes :-)
-
Henrik:
-
Should we take this draft on? 0 say yes, 3 say no
-
Henrik:
-
Should we either here or in a BOF or in MONAMI6 work on multihoming on MIP4? 25
say yes, 0 say no. Will consult with Pete and IESG to figure out how to
proceed.
|