[Mip4] Minutes from IETF-72 in Dublin
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Mip4] Minutes from IETF-72 in Dublin
Here are proposed minutes from IETF-72 in Dublin.
Many thanks to the note-taker, Vijay Devarapalli, for the notes!
Comments to the list and chairs, please.
Best,
Henrik
========================================================================
MIP4 WG Minutes
===============
MONDAY, July 28, 2008
1300-1500 Afternoon Session I
2. Document Status
WG Documents:
draft-ietf-mip4-rfc3344bis
- Waiting for Shepherd Writeup
draft-ietf-mip4-generic-notification-message
- New version needed
draft-ietf-mip4-nemov4-fa
- Please review and comment
draft-ietf-mip4-nemov4-dynamic
- Re-submit, review and comment
draft-ietf-mip4-gen-ext
- Review and discuss based on
draft-deng-mip4-host-configuration-00.txt
draft-ietf-mip4-rfc2006bis
- Waiting for final revision
draft-ietf-mip4-dsmipv4
- IESG Processing, waiting for processing at the same time as DSMIPv6
RFCs Published:
draft-ietf-mip4-nemo-v4-base
- RFC 5177
draft-ietf-mip4-mobike-connectivity
- RFC 5266
draft-ietf-mip4-vpn-problem-solution
- RFC 5265
3. DHCP-based Host Configuration
draft-deng-mip4-host-configuration-00.txt
Henrik - Why use the MAC address instead of the NAI
Hui - Captured and analyzed DHCP messages. They all use the MAC address, so
recommended using the MAC address
Henrik - The use of MAC address is common, but does not prevent other forms
of identies from being used
Pete - 3G cellular links do not have the MAC address
Henrik - It should be possible to use NAI as the client identifier
Kent - Using the NAI for client identifier is common too
Kent - On the use of broadcast IP address. HA is supposed to replicate the
broadcast packets and sent to every mobile node. Is that applicable here?
Hui - Yes
Kent - This is a bad idea. HA should not be broadcasting these DHCP messages.
So prefers using unicast addressing for the DHCP messages.
Kent - Previous drafts spoke about informatiom from both the home and visited
networks. This is addressed in the current draft.
Ahmad - What is the intended status? The messages are already there. We are
only describing how to use these messages with MIP4
Henrik - Informational might make sense.
Jari - Are there examples of visited network information that you would want
to delivered to the MN
Kent - To get back to Jari on that
Henrik - Why not use DHCP directly in the visited network to obtain
information from the local visited network?
Pete - There might be an issue with sending a DHCP message locally broadcast
at the same time as sending one to the home network
Henrik - Do the local DHCP request before setting up a tunnel with the home
agent
Pete - There is an issue with FA mode. There is no local address for the MN to
use.
Ahmad - There was a draft from WiMAX about sending a broadcast/multicast
packets locally. Maybe that draft could be considered
Pete - We need to look at the general issue of local breakout for broadcast
packets.
4. Generic Notification
draft-ietf-mip4-generic-notification-message-06
Ahmad & Sri - Some confusion.
Henrik - There is agreement already to make the changes to the draft. There is
no point in re-hashing the discussion. Lets move on
Vidya - Is integrity protection optional?
Sri - No
5. Better Than Nothing MIP4 Fast Handovers
draft-doswald-robert-mip4-btn-fmipv4-00.txt
This document proposes a complement to fast handover mechanisms
according to RFC 4881 and RFC 4988. Those require the presence
of Foreign Agents; while the mechanism proposed here uses a direct
connection to the Home Agent.
Sri - What is the motivation for this? Any use-case?
Alistair - Looking for a solution to improve handovers without a FA
Kent - Can you give an example of such a network?
Alistair - Has a use-case for mobiles using an existing infrastructure.
(Some sort of street cleaning robots. )
Kent - What kind of access technologies?
Alistair - We are using WiFi and some 3G cellular technologies
Henrik - This looks like delay tolerance is the most important thing
here rather than fast handovers
--
Mip4 mailing list: Mip4 at ietf.org
Web interface: https://www.ietf.org/mailman/listinfo/mip4
Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.