[Mip4] Minutes from IETF-72 in Dublin

Henrik Levkowetz <henrik@levkowetz.com> Fri, 29 August 2008 17:13 UTC

Return-Path: <mip4-bounces@ietf.org>
X-Original-To: mip4-archive@optimus.ietf.org
Delivered-To: ietfarch-mip4-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0253A3A69C5; Fri, 29 Aug 2008 10:13:43 -0700 (PDT)
X-Original-To: mip4@core3.amsl.com
Delivered-To: mip4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934233A69C5 for <mip4@core3.amsl.com>; Fri, 29 Aug 2008 10:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXhlJpvXSw3M for <mip4@core3.amsl.com>; Fri, 29 Aug 2008 10:13:40 -0700 (PDT)
Received: from merlot.tools.ietf.org (unknown [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id EB85F3A68C0 for <mip4@ietf.org>; Fri, 29 Aug 2008 10:13:39 -0700 (PDT)
Received: from localhost ([127.0.0.1]:56837 helo=chardonnay.local) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <henrik@levkowetz.com>) id 1KZ7XR-0006VM-H8; Fri, 29 Aug 2008 19:13:33 +0200
Message-ID: <48B82E3D.7010201@levkowetz.com>
Date: Fri, 29 Aug 2008 19:13:33 +0200
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: Mobile IPv4 Mailing List <mip4@ietf.org>, Mip4 Chairs <mip4-chairs@tools.ietf.org>
X-Enigmail-Version: 0.95.7
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: mip4@ietf.org, mip4-chairs@tools.ietf.org, henrik-sent@levkowetz.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false
Subject: [Mip4] Minutes from IETF-72 in Dublin
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mip4>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mip4-bounces@ietf.org
Errors-To: mip4-bounces@ietf.org

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@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/