[Mip4] IETF 67 Meeting Minutes

["McCann Peter-A001034" <pete.mccann at motorola.com>]

Please find the draft meeting minutes attached.  Please send any
corrections
to the mip4 list ASAP.

-Pete

Meeting notes for MIP4 WG:

Start time 3:14pm

Agenda presented:

Mobility for IPv4 WG
=======================================================================

WEDNESDAY, November 8, 2006
1510-1610 Afternoon Session II
Harbor Island I
=======================================================================

CHAIRS: Henrik Levkowetz <henrik at levkowetz.com>
        Pete McCann <mccap at petoni.org>

AGENDA:

1. Preliminaries                                         10 min, Chairs
   - Blue sheets
   - Note takers
   - Jabber scribe
   - Agenda bashing

2. Document Status                                       15 min, Chairs

    Active:
      draft-ietf-mip4-dsmipv4				Active 	Henrik
      - Comments requested

      draft-ietf-mip4-fmipv4			  	Active 	Pete  
      - Last Call: 2006-09-05
      - Revised draft submitted 2006-10-22

      draft-ietf-mip4-gen-ext			 	Active	Pete  
      - Last Call: 2006-10-19
      - Good comments, revised draft needed.

      draft-ietf-mip4-message-string-ext	  	Active 	Henrik 
      - Last Call: 2006-06-13
      - Needs Shepherd Writeup

      draft-ietf-mip4-mobike-connectivity 	  	Active 	Pete  
      - Last Call: 2006-04-14
      - Needs 2nd Last Call, next week

      draft-ietf-mip4-rfc2006bis 		  	Active 	Henrik
      - Revised draft needed. Nudge needed

Action item: Kent to revise draft, wasn't clear had responsibility.  
Henrik mentioned that Hasse was the reviewer.


    Recently Expired:
      draft-ietf-mip4-radius-requirements	  	Exp. 	Pete
      - Needs review!

Vijay ... why are the requirements needed?
Henrik explain that requirements draft was asked to be done.
Henrik: There were strong objections. During the discussion we were are asked to do first the requirements document and then follow up. It is not something we thought we need, but we were asked for it.
Madjid: Why do we need to go back and resubmit it. The IESG was supposed to review.
Henrik: do you expect the IESG to look at it if the WG hasn't looked at it. If it nobody read it it's an individual draft.
Jari: Let's do the review and move it on.
Madjid: is it possible to do the review and resubmit after?
Henrik: Yes.


      draft-ietf-mip4-rfc3344bis 		  	Exp. 	Henrik
      - New revision almost submitted

Perkins: Inconsistency issue with copying UDP port number
Henrik: Put the issue on the ML
Pete: Need to resubmit - the draft was rejected from internet-drafts at ietf.org

      draft-ietf-mip4-vpn-problem-solution	  	Exp. 	Henrik 
      - Last Call: 2006-04-24
      - Needs Shepherd writeup.

    IESG Processing:
      draft-ietf-mip4-reg-tunnel		  	IESG  	Pete  
      - Last Call: Several times, last time 2004(?)
      - New revision submitted, needs verification of issues settled.

Jari: I looked at the spec, and the major comment from Vidya has been
  addressed, but I brought that up to Vidya and she didn't agree. If we
  can't come to conclusion, I'd like to say this targets experimental so
  the bar is lower.

ACTION ITEM on chairs: get Vidya, authors and chairs together.

    RFC-Editor's Queue:
      draft-ietf-mip4-rfc3012bis		  	RFC Ed Queue	
      draft-ietf-mobileip-lowlatency-handoffs-v4  	RFC Ed Queue	

3. New charter proposals                                 

3.1 MIPv4 based Moving Network (NEMO) support		  5 min, Chairs

    It been proposed to standardise some moving network
    support, and a proposed charter addition has received
    favourable support on the mipv4 list.

Henrik: I'd like to ask people here regarding the base moving network
  support. Do people have comments?
Sri: what happened to 3519bis draft?
Henrik: need to make sure it's on the charter
Sri: almost done with changes

Vote for work item:

yes: 10
no: 0

charles Perkins: RFC 2002 has text about Mobile Router - no
  opposition, I just noted that it's a good idea to be more specific
  about what is the specific change in charter

Henrik: The charter text was posted to the list, pls comment.
Henrik: The room is in agreement with the list so we'll take this on.


3.2. Generic notification mechanism                       5 min, Chairs

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

    It has been proposed to also add this as a work item
    to the charter, and the list response has bee favourable

Vote for work item:
yes: 7
no: 0


4. FMIPv4 updates                                         5 min, Rajeev

   draft-ietf-mip4-fmipv4

Vijay presented WGLC revisions.  Most were clarifications in the description.

Protocol for v6 was simpler because we didn't have to deal with
foreign agent and collocated care-of address mode. We clarified the
text to explain better the FA care-of mode/collocated care-of modes.

reverse tunneling from MN to HA

New section added "Factors Affecting Handover".  Need review.
Better explanation of what we're trying to optimize, delays factor
contributing to overall picture.

Pete: any comment? No comment.


5. The MIPv4 nemo base document				  5 min, Alex P.

   draft-ietf-nemo-v4-base

   This document was earlier handled by the NEMO working
   group.  If the new charter containing work on MIPv4
   moving networks, it is expected that this will be the
   base document taken forward by the MIP4 working group.

Alex presented nemo basic support.  This document was presented to NEMO WG.
First presentation of this topic in this WG. RFC3344 already has
language about it. The protocol is an extension to mip4 which allows
for movement of host behind a mobile router.

The protocol was first presented to NEMO WG which has already designed
3963 for v6 moving networks. We last called that document in NEMO.

The protocol is very simple: it extends registration request and
reply. The Foreign agent isn't involved in this protocol.

The MN don't need to have mobility support.

It uses a prefix table to do security checks where a rogue MR pretend
to own a prefix own by another legitimate MR.
                 
These are the extensions parameters. You can have several prefixes in
this parameters both in request and reply.

There are two mode of operation: explicit and implicit. 
Implicit is like in 3344. Explicit exposes the prefixes in these
messages and should help debugging.

We went through several WG meeting, we went to LC in NEMO. Not many comments. 

We have an ethereal implementation decoding packets. We don't have yet
IANA numbers, it would be great if we could obtain them instead of
TBA.

The draft originally had very much text trying to deal with many
aspects. @e realized that it's very complex and complicated to make
everybody happy -- MR, HA, FA.
We tried to separate extensions between those.

Vijay said current HA sets up a tunnel to CoA and another tunnel to
MR's Home Address.

Remove optimization method.

Vijay: the IANA numbers, I don't think you get numbers before you get
into the queue.

Alex: Yes that's true, but we would like to have for interoperability.

Vijay: Something we've done in the spec is to recommend values in the
spec, and asking they were removed when in the RFC editor. But is has
problem.

Henrik: Yes please don't do that, but rather use experimental values
as per the guidelines we have established.

Alex: Ok we'll use experimental values. OK that was last issue.

Georges: You're going to remove old text about foreign agent? The spec
will describe protocol betwen MR and HA and will have nothing to do
with FA?

Alex: That's the intent, but we might want that to work with
unmodified 3344 FA

Henrik: Something more about experimental values. In case everybody doesn't know this, 4046 describes guidelines on how to use values for experimenting.

Alex: But it still need to be agreed about values....

...

Kent: Comment from Vijay, just want to make sure. 
Comment on removing some optimization. For optimizing ... in CCoA mode....

Alex: .. it's not enough for implementers. Perhaps have more complete
descriptions but outside of the base.

Kent: The unoptimized would be in the draft...

Alex: We should discuss that later.

Kent: What we're trying to accomplish is support of legacy FA. I don't
think that we can ....

Georges: The optimization that you're talking about is ...

Alex: ...

Georges: There's no FA in this case. We can add this to the FA
extension. It is not clear if that coordination is needed.

Alex: It might be that in practice this optimization doesn't require
optimization at the FA.

Henrik: what wil happen before we decide is a new charter, then we can
decide. I don't expect any problem with it, but that's the formal way
of doing it.

Alex: Ok thanks.



6. MIPv4 nemo extension documents			 10 min, George

   draft-tsirtsis-nemov4-dynamic
   draft-tsirtsis-nemov4-fa


George presented DSMIPv4 update

WG draft published in July, since then integrated comments and
corrections plus clarifications, soon v01.

This prefix delegation text. the spec allows for two ways ...

... I have to review the prefix delegations

Sri: so you try to ...

Georges: I'm just trying to use as is, so that I don't have to change it.

Now discussing NEMOv4 extensions

you have implicit or explicit mode. Dynamic mode allow prefix to be
sent from MN to HA set to zero so that agent can fill in.

Sri: DHCP PD draft by Pascal, is this used in this draft?
George: Not clear if anything needs to be changed

Next step: accept as WG items? It's linked to the base support.

Alex: The DHCP dynamic allocation, if we have a clear idea about HA
being a server and the MR a relay and the foreign agent a sub-subrelay
I think .... You said that HA allocates Home network prefix to MR. I
think it's not always the case.

Georges : it is a relay

Alex: so if it is relay it doesn't allocate anything I'd like to say
that FA can also do it.

Alex: The FA and HA could be linked. Are you open to modify the description?

Henrik: on a high level I want to say that provided that we take on
this work (i think we should) these are natural ways of doing things,
in general it makes sense.

Pete: show hands.. how many people think we should have that in the
charter: 15. Opposed: none.



George: Ask WG to review the Flow ID Ext draft, not requesting as WG item

Jari: I think there's enough on the charter, so let's not go there.

Kent: make sure that 2794bis didn't fall off the WG charter

Pete: expect a new version to be published and reviewed by WG


End meeting: 4:03pm




-- 
Mip4 mailing list: Mip4 at ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/