Subject: [Mip4] Meeting Minutes for mip4 at IETF59

From: Pete McCann <[email-masked]>
Date: Wed, 31 Mar 2004 11:07:02 -0600

Hi,

It's taken a bit longer than expected to put these together, and,
unfortunately, the submission deadline is almost upon us (this
Friday).  But, here are the draft meeting minutes for your review.
Please send any comments or updates to the list by tomorrow so we can
include them in the final minutes for the proceedings.

Many thanks to Jayshree Bharatia and Pascal Thubert for taking notes
during the meeting.

-Pete

MIP4 WG Minutes (Monday, March 1, 2004, 1930-2200)
==================================================

1. Topic: Document status by WG Chair

aaa-nai => In RFC editor Queue
aaa-key => Publication requested
lowlatency-handoffs => Publication requested 
vpn-problem-statement =>  Under IESG evaluation 
reg-tunnel => Chair writeup needed
rfc3012bis => Await resolution of one issue
dynamic-assignment => Require one more revision
experimental-messages  => Await resolution of one issue
vpn-problem-solution => Review needed
rfc3344bis => Issues resolved but the draft is not published.
2006 => Need mib doctor
------------------

2. Topic: Update on 3012bis Issue by Pete McCann

Couple of options were presented in last meeting to resolve issue on indicating
an error to the MN by the FA upon receipt of the Registration request from the
HA. These options are whether to overwrite the HA's error code or to insert a
new error code extension at the FA. The later option was preferred in last IETF
meeting which also introduces a dependency on perkins-faerr...

Charlie clarified that this was the reason MIP4 working group decided to have
the new draft (perkins-faerr) so this dependency is justified. This implies that
a new reference document need to be added to the RFC3012bis draft. The issue and
proposal will be posted on the mailing list soon.  
------------------

3. Topic: Experimental-messages issue by Alpesh Patel
There is one issue unresolved for this draft at this time. 
The issue is whether to define an experimental sub-type. Adding new sub type
provides advantage such as implementation will need minimal code change from
experimentation to standardization. If this subtype is not defined then the same
functionality will be achieved using experimental extensions. It introduces a
disadvantage of reserving sub-type number from allocated numbers.  

Comments: 
It was clarified that the format of the extension are already defined in 3344.
Pete pointed out that it doesn't make sense to do at this time. It should be
done case by case basis. 

Conclusion:
It was agreed not to define experimental sub-type. This was determined by the
humm in the meeting.

4. Topic: Dynamic Assignment By Alpesh Patel

Issues: 
1. Add subtype field in Redirected HA Address Extension. This issue is resolved
and the solution will be added in the next version.
2. To align the HA address at 4-byte world boundary. This issue is resolved and
will appear in the next version.
3. The current scheme does not allow dynamic HA registration (AZOA HA address)
beyond first registration. The response of this issue was that it makes sense to
use AZOA as HA address while dynamic assignment is in progress.  
4. An issue was related to using RRQ with unicast HA address for dynamic
assignment. The response of this issue was that for Dynamic HA assignment,
unicast HA address will not be used.
5. In addition to AZOA HA address, provide an extension for additional
information to distinguish different cases of dynamic HA assignment. It seems
authors require further clarification on this issue. 
6. Editorial issues will fix in the next version of the draft. 

Comments: This draft is diverting from 3GPP2 requirements so authors like to
know the input on the implication on 3GPP2. Pete mentioned that most of the
changes are still essential. It is up to other standards to decide whether they
want to adopt the current changes.

5. Topic: Optimized Mobile IPv4 UDP Encapsulations By Farid Adrangi

Motivation is to minimize MIPv4 data packet overhead when UDP
encapsulation is used and most of mobile node's data traffic is
destined to one particular correspondent node. The applicability is on
MIP/VPN or basic IPSec-over-MIP4 and also VoIP over MIP. The idea is
to specify an extension to be used in congestion with RFC 3519 to
enable overhead extension. A scenario was explained with extension
"Preferred-CN".

In this draft, a new state "preferred" CN is defined in mobility
binding apart from the new extension. A new flag is also defined in
MIP Tunnel data Message header indicating optimized UDP encapsulation
in use. Examples of how packet processing works (inbound and outbound)
were discussed in brief. The author asked working group opinion on
whether this is something which can be standalone or it is viewed as
an extension of RFC3519.

Comments: 
- If we take on this, need a charter change.
- This defines an adhoc header compressoin for IP header. 
  For VOIP, there are multiple schemes that exist and save more, such as ROHC.
- ROCH, CRTP, etc also apply to any number of flows. 
  TCP, UDP and RTP compression at the same time. Would be useful to look
  at the whole architecture. Which are the points where header compression
  can be used?   Endpoints?  Middelboxes?
- The Limit is up to 2 layers for the compression using ROHC. Need to look at
  specific cases. But more generic solution is preferable.
- For the question, why only one CN was picked in the draft, the author
  clarified that it is still for further study. The chair mentioned that the
  same question was also raised earlier on the mailing list. 

Conclusion: The charter needs to be changed if it is decided to accept this
draft. Further discussion is require on this topic.
-----------------

6. Topic: Fragmentation MTU Extension by Farid Adrangi

Large packets sometimes dropped by routers. This seems like a realistic
deployment issue. Solution is to define an extension with preferred MTU for
reception. MN and HA sends MTU independently. Applies to both IP-IP and
IP-over-UDP. This work may be proceed as a stand-alone or an extension to
RFC3519. This draft focuses only on the tunnel between the HA-MN. 

Comment:
It was question on the use of solving only one leg of the route. It seems
solving this cases would solve majority of the cases according to the author. 

Conclusion:
It seems not many people have read the draft. Further discussion will be on the
mailing list. The charter may need to be changed if adopted as a WG draft.
------------------

7. Topic: FA Error Extension by Charlie Perkins

This draft was written to solve the problem of RFC3012bis but the problem is
generic. The problem is that the FA doesn't have any way of indicating the error
to the mobile node in the successful Registration received from the HA.  For
this, a new faerr extension has been defined. This extension is added to the
Registration Reply whenever there is a need to indicate an error. This draft is
very short and going to WGLC as soon as it appears in the Internet Draft
repository. this draft will be referenced by RFC3012bis.
-------------------

8. Topic: mobility+IPv4/v6 interworking

Experiments being carried out to support MIPv4 nodes roaming in IPv6 networks
and MIPv6 nodes roaming in IPv4 networks.  Several proposals for how to do this
exist.

Henrik proposes a (non-)bar BOF to discuss the need for it.
-------------------