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 Pete McCann 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@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