[Mip4] IETF-64 Minutes

========================================================================
			 Mobility for IPv4 WG (mip4)
========================================================================

THURSDAY, November 10, 2005, 1300-1500
========================================================================

CHAIRS: 
        Henrik Levkowetz <henrik@levkowetz.com>

        Pete McCann <mccap@lucent.com>

AGENDA:

1. Preliminaries                                        10 min Chairs
------------------------------------------------------------------------

   - Minutes
   - Agenda bashing

   No comments on agenda

2. Document Status                                      15 min Chairs
------------------------------------------------------------------------
   draft-ietf-mip4-rfc3344bis           

   New revision submitted right before the meeting.
   Next: Chair writeup and publication request

   Comments:
      Henrik: 
        Charlie submitted a new version before the meeting. One request for a
        new error number was done. 

      Charlie: 
        submitted the weekend before the deadline but it has been on the
        website for a month and there has been no change. 

      Vijay: 
        the target is draft standard?

      Pete: 
        we had some subsequent technical changes therefore we need to
        recycle to proposed.

      Henrik: Yes, we had indicated draft standard but people need to be
          aware that we have done changes.

      Vijay: not exactly sure what changes were made? 

   draft-ietf-mip4-vpn-problem-solution         
      Ready for WG last call

   draft-ietf-mip4-dynamic-assignment           
      Waiting for AD Go-Ahead::AD Followup

   draft-ietf-mip4-faerr                        
      Waiting for AD Writeup

   draft-ietf-mip4-reg-tunnel                   
      AD Evaluation::Revised ID Needed

      This draft has an Appendix which the authors don't agree
      on how to handle.  We've had an independent review of
      the Appendix too, and need to decide what to do with it.

   Comments:
      Henrik: 
         Had a long and painful story. We may be splitting up the draft
         into an appendix and the main part and then do the appendix as
         informational.  

   draft-ietf-mip4-rfc3012bis                  
      Waiting for AD Writeup

      Several reviews done for AD,
      Need to decide whether to fork off the Generalized 
      Mobile IP Authentication Extension as a separate draft.

   Comments:
      Henrik: Jayshree is doing the few changes..

   draft-ietf-mobileip-lowlatency-handoffs-v4   
      IESG Evaluation::AD Followup

      (Just re-submitted by Karim, ready to go to RFC Editor)

   Comments:
      Henrik: has been approved.

   draft-ietf-mip4-rfc2006bis                   
                MIP-centric review done, new revision needed

   Comments:
      Henrik: 
        Kent is going to do the review alone or with help. Hopefully
        ready for MIB doctor. 

   draft-ietf-mip4-experimental-messages        RFC 4064

   draft-ietf-mip4-vpn-problem-statement        RFC 4093

   Comments:
      Henrik: that is nice.

3. New charter                                           5 min Chairs
------------------------------------------------------------------------
   http://mip4.org/charter/mip4-charter-2005-09-08.html

   Comments:

      Henrik: 
        Did not get to the IESG slate. No indication of negative
        results. If you have comments, this is your last chance. We
        have a new work items that will make into charters. Until that
        is cleared, we will not take new work items. There are some
        presentation are here for addition to the charter but that is
        the bottom line at this point.    

4. New WG drafts:                                       20 min Author
------------------------------------------------------------------------
   Status summary, open issues:

   draft-bharatia-mip4-gen-ext                        5 min Kent

   Presentation:
     http://www3.ietf.org/proceedings/05nov/slides/mip4-2.pdf

   Presentation by Kuntal. 

     The draft aims to send conf info from HA to the mobile during the
     initial exchange.

     Changes from -00 to -01 is formatting of configuration parameter
     based on DHCP options, no longer MIP-specific

     Also allows the MN to request config info from the home or visited
     network and that at the same time if needed.

     Here we reuse DHCP codes so you don't have to define new
     subtypes. Adopted the DHCP option code structure and formatting.

     received some comments on the mailing list and updated the draft based on that.

     A generic extension to be used for the method was shown, including
     type, length, entity-type (distinguishing between FA ad HA), and
     config data (conf parameters are packed here).

     an example of config parameters were shown.

     open issues:only DHCP based parameters are considered. Do we have to
     define non-DHCP parameters?

   Comments:
      Sri: 
	You may also need a default realm for DNS queries.

      Pres: 
	You can basically piggyback DHCP info with this.

      Henrik: 
	Can we define this as DHCP-only information and if we need
	non-DHCP we define a different extension for that later.

      Kuntal: 
	good idea

      Yoshi: 
	DHCP option length 

      Kuntal: 
	If all the option are going to fit in one or multiple NVSE.

      Kent: 
	We have talked among ourself on what to do with the DHCP versus
	non-DHCP, we think we should built that at subtype level rather at
	type level.

      Henrik: either way works for me.

   draft-devarapalli-mip4-mobike-connectivity         5 min ???

   Presentation:

     http://www3.ietf.org/proceedings/05nov/slides/mip4-3.pdf

   Presented by Vijay: 

     Brief update from 00 to 01:

     01 has been submitted with not
     many changes, some based on Jari and TJ's reviews.the target is
     going to a BCP doc. some additions on when this mechanism is
     used. the idea is use this for IKEV2. and IKEv1 reference was
     removed.    

   draft-sastry-mip4-string-extension                 5 min Kent

   Presentation:

     http://www3.ietf.org/proceedings/05nov/slides/mip4-0.pdf

   Presented by Kent: 

     Update since version 00:

     update to 02 some changes regarding the revocation messages.
     Changes on the use of message string extension, correction to
     security considerations.  Some changes based on TJ's comment and
     addressed most of the issues.

     Can we have some comments? it seems to be pretty straight forward and
     should go to last call.

   draft-nakhjiri-radius-mip4                         5 min Madjid

   Presentation:

     http://www3.ietf.org/proceedings/05nov/slides/mip4-1.pdf

   Presented by Madjid:

     Update since version 01:

	 Clean up of the attribute section. 

     Review from Jari Arkko. There was a question on why the registration
     request was being hashed. this was to avoid the attribute size issue
     in the future if the reg. req gets too big.

     Diameter can tell whether you are dealing with a HA or a FA. for
     RADIUS you can do this only by some information in the
     attributes. Something new is needed. A new MIP-Agent type

     Some work remaining. More details on Diameter AVP-RADIUS attribute translations

     Issue with MN-AAA authenticator and MFCE. please fix 3012bis.

   Comments:

     Vijay:
       Don't agree with CCoA mode calculation in 3012bis draft

     Kent:
       Discusses already on WG. Folks agree there are 2 solutions in RFC 3012.

     Henrik:
       Take it to the WG alias.

     Henrik: 
       We've had quite a bit of discussion with RADEXT chair and need to make
       clear what we are doing here and how we separate that from what it is
       done in Diameter. There should be a doc on this.

   draft-koodli-fmipv4                                5 min ???

     Nothing to go over here.

5. IPv6 over MIPv4 and MIPv4 over IPv6.                  5 min Chairs
------------------------------------------------------------------------

   Taking on some work in this area has been discussed earlier, during
   IETF-62.  The question has been raised by some people again, in view
   of the work on MIPv6 over IPv4 and IPv4 over MIPv6 which is being
   done in the MIP6 working group.

   Comments:

      Henrik: 
        Authors have asked to reconsider this again. He likes to ask
        for a HUMMM on which way to go. No decision is to be done here.

      Hesham: 
        The aim is to allow the operator to do IPv6 over MIPv4 and a
        similar work is done in MIPv6.

      Kent agrees.

      Vijay:
        I like to discourage these sort of things in general. It is
        better to move on to IPv6 rather to do run things this way.

      Henrik: 
        Not everybody agrees plus there are specific cases that you simply cannot do it.

      Hesham: Philosophically is better to force people on these things.

      Rajeev K:
        questions what is the relation between this and the traversal work in MIPv6.

      Henrik:
        this only deals with MIpv4 and not MIPv6 and that is why.

      Kent:
        the goal is to use one signaling protocol.

      Pete: 
        chair hat off, I submitted this draft a while ago. It makes sense IPv6 over MIPv4.

      Vijay: 
        personal experience. Operators are willing and want to move to IPv6.

      Henrik: 
        we are not proposing people to not move to IPv6 here. 
        for information only how many people want to take this or not to take this on.
        The HUMM for for is stronger than the HUMM against.

      Mohan: 
        Scope of work?

      Chairs: 
        Both drafts.

   Related drafts:
      draft-tsirtsis-v4v6-mipv4

      draft-larsson-v6ops-mip-scenarios

6. GRE Key Extension for Mobile IPv4                    10 min Parviz
      draft-yegani-gre-key-extension

   GRE (Generic Routing Encapsulation) [ RFC 2784 ] is one of the
   encapsulation formats permitted by RFC 3344.  GRE may use keys
   to distinguish different tunnels from each other. [RFC 2890].
   This draft proposes a MIPv4 extension to communicate GRE keys
   between MIPv4 tunnel endpoints when requesting GRE tunnelling
   for MIPv4 traffic.

   Parviz presented. 

      3344 optionally supports GRE tunneling.
      The proposal is to allow this tunneling.

      there is a need for subscribers who are home in 3GPP. You cannot
      really distinguish between traffic streams based on HoA, CoA. So we
      need a new extension.

      The idea is to allow both HA and FA to assign different keys (assymetric). 

      There are situations that these keys can be available to HA and FA.

      But in 3344 the MN can set the G bit. Here we should be able to based
      on policy overwrite the G-bit setting and request a GRE tunneling.

      Henrik: clarification, we are talking about GRE key, not encryption key.

      Mohan: is it for FA CoA or colocated mode

      Parviz: no for both.
       This is for FA CoA mode only.

      Parviz: the HA can assign two addresses to the same subscriber because
      it is private addresses.

      back to presentation: GRE key assignment is outside of the scope. The
      behavior of FA is new, the G-bit overwriting is not the in RFC. The
      impact is that key allocated by the FA can be used for FA-to-HA use.

      No changes to the MN behaviour.

      Questions/ comments/ working group item?

   Comments:
      Kent: 
        good idea. When HA is wholesale, this is a good idea. Today the
        only solution is to have different instances of HAs.

      Pete:
         I like the idea, it is done 3GPP2. But not comfortable with G-bit overwrite.

      Parviz:
         the final decision is by the HA and the HA can reject and
         finally have a different tunneling.

      Henrik:
         what happens to MN-HA-AE if you can the G-bit?

      Parviz:
         G-bit in the GRE extension is not changed. 

      Kuntal:
         why would the MN care whether you are GRE or not? why does
         have to be based on MN request.

      Kent:
         when the tunnel is between FA and HA, what is the role of MN?
         this is breaking the paradigm of the 3344.

      Sri:
         consistent. The extension is added by the FA.

      Parviz:
         which entity should assign those keys, FA or HA or both.

      Kuntal:
         both. the key that FA wants to receive should be specified by
         the FA and the one HA wants should be assigned by HA.

      Kent:
         Unidirectional and bidirectional should be supported. HA should
         be able to assign the keys for both sides.

      Kuntal:
         can't see a use case for when we want the HA to allocate both.

      Pete:
         receiver should allocate the key.

      Kent:
         agree, it is ok for the HA to allocate the key, technically.

      Henrik:
         may simplify what FA wants to do, but does not simplify the FA code.

      Kent:
         don't think implementation pov either way is harder.

      Kuntal:
         should we really have to have both options in the draft.

      Henrik:
         proposing to have the receiver assign the keys.

      Kent:
         Agree with everything but it does not hurt to add it and make it optional.

      Kuntal:
         how does the FA know what sort HA is it talking to.

      Henrik:
         Kent to propose some text and take it to the list.

7. Generic Notification Message for Mobile IPv4         10 min Hui
------------------------------------------------------------------------

      draft-deng-mip4-generic-notification-message-00.txt

   This document proposes a protocol enhancement that allows Mobile
   IPv4 entities to asynchronously send and receive explicit 
   notification messages.  The Registration Revocation mechanism of RFC
   3543 could have been specified using a message such as the one
   proposed here, had it been available at the time.

   Presented by Hui

   Presentation:

      in some cases, there is a need for MIPv4 entities to send and rx
      asynch notification events during a session. 3344 does not provide
      specification for this.

      This doc defines generic message and notification model for this process.

      does not define specific notification extensions.

      some examples are presented. 

      HA initiates a notification to MN, FA initiates a notification to MN, another case.

      Generic notification msg send by mobility agent to inform another
      mobility agent or a MN.

      3 flags were defined

      flag A, bit identifies if ack to the notification msg is need.
      other fields of the message were defined.

      issues: to discuss whether a notification MUST be acked and whether
      the use of flag is good or not.

      issue 2: R bit in Agent advertisement

      usage examples were presented: 

      registration revocation, asynch. user notification (out of credit,
      coming service interruption), asynch MN or agent notification, may be
      necessary for high availability scenarios with long reg. life times.

   Comments:
      Henrik:
         comments on the issues and the general idea

      Kuntal:
         similar in MIP6 regarding HA switch. I think this is a good
         idea, but I am struggling with the use cases and who will be doing
         this.  Why would you notify the HA when the system is going down, and
         create more traffic.

      Hui:
         Just one BS with access channel in cellular won't cause that much traffic.

      Henrik:
         you are not sending 1 Million notification, it is good idea to
         cover in the draft for planned maintenance, when you notify that you
         want to take the HA down in so and so hour.

      Kuntal:
         still you may have thousands of MNs maintained by HA, still
         that is a lot of messages.

      Henrik:
         This a small subpercentage of the overall traffic.

      Kuntal:
         why not use reg. revoke. why this one?

      Henrik:
         Are you supposing that we should do this using another message? don't agree.

      Kuntal:
         reg. revoke is done today.

      Kent:
         make this optional, not mandatory.

      Henrik:
         We should put our foot down and say no if we think something
         is causing a lot of problem (personal opinion).

      Hui:
         3GPPX wants to use SIP SDP for this.

      Parviz:
         not sure I can see the use case scenario for this.

      Hui:
         the real scenario is HA switch.

      Sri:
         don't focus on where it is used, but focus on whether this is
         useful or not. example is prepaid.

      Kuntal:
         last comment on prepaid and people use text messages for that
         purpose. HA has no business sending notification to the MN when
         account is up.  for MN-FA notifications you would need specific
         bootstrapping methods.  If something is already solved in the industry
         we don't try to go and design a new solution.

      Kent:
         right now the revocation only goes to FA, but not to the MN, so
         it may not be the right way to do it but we do have a MN-HA
         association. In deployments people don't completely shut down the HA
         anyway, but if you want to do that more power to you.

8. Mobile IPv4 Fast Handovers for 802.16e networks       5 min Junghoon
------------------------------------------------------------------------
      draft-jee-mip4-fh80216e

   IEEE 802.16e is an amendment of 802.16 ("WiMAX") which extends it
   from fixed terminals only to fixed and mobile operation.
   This document describes how Mobile IPv4 Fast Handover can be used
   IEEE 802.16e link layers.

   Presented  by Junghoon.

   Presentation:
      rfc 4068 is a work item (FMIPv4), so he proposes fmipv4 over 16.
      some of related work is done in MIPshop, so he is mentioning. 
      some mobility is done in layer 2.
      predictive and reactive (??) modes were discussed.

      Is there interest in this work? is this a topic for this working group?

   Comments:
      Pete: 
         the problem is that FMIPv6 over X is supported in MIPSHOP, but
         they have strict charter on v6. Should we get into FMIP stuff here?

      Rajeev: 
         True, may be it should be here.

      Parviz:
         why just 16e? should be FMIPv4 over anything?

      Pete:
         you need to take the specifics of the link to make it working.

      Hannes:
         it is good stuff.

      Kent:
         it is interesting.

      Henrik:
         I can predict problems down the line when we want to go for publication.

9. Using multiple interfaces for increased throughput    5 min Srinivasa
------------------------------------------------------------------------
        draft-srinivasa-mip4-mir-00.txt

   This document defines enhancements that allow a MN, when away from
   home, to simultaneously use multiple connected network interfaces
   so as to obtain higher aggregated bandwidth.

   Henrik:
      Author is not here. it is interesting work. uses multiple
      interfaces to stream videos to remote villages in India because the
      existing cellular systems and it is actual deployment. It is mature
      for adoptions. As an example of what you can do in a multiple
      interface scenarios.

[Mip4] IETF-64 Minutes

Attachment: signature.asc