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-nakhjiri-radius-mip4-01.txt

Slides: http://mip4.org/ietf63/mip4-radius.pdf

No slides were received for this agenda item before the meeting, and Kent was not present in the room. Skipped here, but inserted as agenda item 12, below.

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.

draft-nakhjiri-radius-mip4-01.txt

Slides: http://mip4.org/ietf63/mip4-radius.pdf

Kent gives a short update on the RADIUS attribute draft. No discussion.