Mobility for IPv4 WG ======================================================================= 1. Preliminaries 10 min Chairs - Blue sheets - Note takers - Jabber scribe - Agenda bashing 2. Document Status 15 min Chairs draft-ietf-mip4-generic-notification-message-08.txt - New version uploaded 3/9. Ready for publication? (no comment in the room) draft-ietf-mip4-nemov4-dynamic-02.txt - We will issue a last call on this soon, but it has lower priority than 2006bis. draft-ietf-mip4-nemov4-fa-03.txt - No interest in continuing. We will drop this item from our charter. draft-ietf-mip4-rfc3344bis-07.txt - Still working on the shepherd writeup. Will be submitted for publication soon. draft-ietf-mip4-udptunnel-mib-01.txt - On hold waiting on 2006bis; then we will issue WGLC. draft-ietf-mip4-rfc2006bis-05.txt - Ready for last call. Will issue soon. draft-ietf-mip4-dsmipv4-10.txt - Published - RFC 5454 draft-ietf-mip4-gen-ext-04.txt - Ongoing discussion on whether to continue this item (see recharter discussion below). 3. Host Configuration 10 min Hui - draft-deng-mip4-host-configuration-01.txt George> Is this informational or are you defining new things Hui> we did not have to define anything new Kent> Regarding the case of no relay in the HA. normal configuration is that the HA is on a virtual link so there are no DHCP servers on the link. In that case you need a relay. Henrik> The WG will consider this during rechartering discussion 4. Multiple Tunnel Support 10 min Sri - draft-gundavelli-mip4-multiple-tunnel-support-00.txt Someone> how do you deal with reordering with per packet load balancing Sir/Kent> These are all just options. Per flow balancing is used by default Someone> how do you set them up dynamically? Sri> forwarding behavior is not modified Hesham> this only identifies tunnel IDs, no policies. This is what we did in MIPv6 but is the same justified in MIPv4? I prefer a single document that handles both MCoA and Flow Bindings. Sri> It's a logical separation. If you do not want to use traffic policies then you can Hesham> But there are wildcard policies to do this Henrik> I have the same issue. If we want to split it we need to make sure that the tunnelIDs allow traffic policies to be possible. Hesham> It is actually a bit messy in MIP6. We for example had default BIDs initially but then was taken out from MCoA which we are now trying to put it in Flow Bindings Kent> There are two functions. With static policies you do not have to couple them together George> We all agree there are two separate functions. The question is whether by splitting it makes it harder to make them work together properly. Henrik> If people have the a short term need for the simpler tunnel ID document done first, if not then it is easier to put them in the same doc Henrik asks for opinions on whether boith functions are needed eventually. Group agreed Henrik asks for opinions on whether there should be one or two documents. Slight preference in single doc. Raj> does this apply for mobile nodes as well as mobile routers? Sri> The concept of connection management is useful. We mostly see market for mobile routers though Hesham> this will be simpler because of less security concerns and no RO we had to deal with in Mext but it is better to do it properly Sri> but is it necessary a single doc or two docs progressed together? Hesham> IMO one document is sufficient, the superset already supports both functions Kent> we do not need to bundle the functions together Someone> will we include the case of home registration? Sri> yes if it is useful 5. Flow Movement 10 min George - draft-tsirtsis-mip4-flowmove-01.txt Pete> Is there anything to add given the earlier discussion? George> No but what is the next step? Pete> We need to merge the two drafts George> OK, will do with Sri/Hesham 6. Home Agent Assisted Route Optimization between Mobile IPv4 Networks - draft-makela-mip4-nemo-haaro-03.txt 10 min Jouni Kent> I mentioned before regarding NHRP Jouni> We did not go for that Anti(via jabber)> looked into it and decided it does not work as well 7. MIP Extension for Ethernet Service Support 10 min Qin Wu - draft-wu-mip4-ether-00.txt Kent> This does not look like MIP but mobile Ethernet. This is a bridged solution and needs to deal with ARP and many other things Qin> Only HA does bridging. FA does not Kent> the point is there is no need to maintain IP tables at all, its all Ethernet Qin>this is a hybrid so that MN can get both IP and Ethernet Henrik> it is not clear whether this makes something new or its just makes certain existing scenarios simpler. Also if an Ethernet packet arrives which carries IP packet, then what do you forward? The Ethernet or the IP packet? So you need to decide whether you are building Mobile Ethernet or only Mobile IP. Discussion between Pete, Henrik, Qin WRT how you decide what to forward between Ethernet and IP at the HA. Frank>Differentiation could be based on the receiving port. This is a use case in wimax which could be elaborated Shan Rahman> I come from wimax bacjground but I do not see a use case for this. You can probably do this with VSE if you really needed to do it. And it would not work for PMIP. Qin>this works for FA CoA and PMIP. The basic idea is to setup binding between the MN's MAC address and FA CoA in the FA and HA perspectively and carry ethernet packet over GRE tunnel between the FA and HA, deliver the specific ethernet Frame from the FA to the MN based on the binding between the MN's MAC address and FA CoA. Shan> it does not work because MAGs have different MAC addresses Qin> The ethernet packet is not sent to the MAG but the Mobile node Qin> served by the MAG, So you needn't care about MAG's MAC address.< potentially answer this question like this :)>> 8. Recharter Discussion 30 min Chairs MCoA and Flow Bindings: The merged document will be taken on BTN Fast Handoff was presented in IETF72…no interest since then, so it is dropped HA Assisted RO? Any objections to taking this on? - Jari: it is not enough for the authors to want to do it…needs support for more people - Raj: the applicability of RO was not clear from the presentation, maybe that can be clarified further before we take a decision. - Sir: I agree, further discussion is needed and more people need to read the draft - Henrik: there does not seem to be enough interest yet - Jouni: someone on the list supported this in the past - Pete: lets find out who and ask again Bulk Revocation: Any opinions? - Henrik: potentially useful but we should not take it on without the author being here - Shah: I am working with the author, maybe it should be consider in the next meeting - Raj: We had simple revocation around for some time and I have not heard any info regarding problems with that - Vijay: we had this before andwas removed in the past. - Kent: there is some value, for the implementation, but no one has asked for it - Shah: we have implemented this in wimax and other networks and we have seen efficiency gains in link failures - Henrik: what the AD thinks? - Jari: defer I think - Henrik: OK GRE-Key extensions: There is a reference to this draft from both PP2 and WiMax - Shah: yes - Vijay: yes - Pete: Hamming vote indicates we need to adopt this Host Configuration: we have two drafts in this and we could probably drop the gen-ext draft. - Someone: how are you going to integrate these? - Pete: they would be separate but both describe configuration without additional overheads from extensions - Kent: we talked about this before. Main issue with DHCP is the support for bcast in HA, which affects performance. In theory it would work but implementation would required to be custom for this. - Henrik: It seems to me that what you need is to handle some bcast as opposed to all bcast - Kent: Yes this is what I meant, it needs special handling so that bcast message is not sent back to all the MNs - Raj: I support the taking up of both the docs and there is need for the 2nd doc specifically WRT mcast/bcast Pete: Hamming on the DHCP config was not deterministic Pete: Hamming on the mcast/bcast draft o Betchet: I think WiMax has moved on and does not need this o Henrik: Despite wimax I think this is generally interest draft o Hamming shows some support and no opposition - Pete: Hamm on dropping the gen-ext draft, maybe premature regarding that we have not decided on the host config draft - Henrik: Ham again on DHCP host config, this time - Vijay: maybe the issue it is that for just a few parameters it might be easier with MIP extensions - Jari: Are you saying they are already doing this? - Vijay: yes with VSEs - Kent: both customers and SDOs have asked and use MIP extensions for this but then we went DHCP way and people lost interest - Henrik: The DHCP provides all the parameters but Kents comment indicates that most people are only interested in a few things and do not care for the rest. I suggest we drop both items for now until things clear up - Jari: this may make sense. were they any other reasons for doing DHCP? - Pete: mainly the fact that we need a new genext option for each dhcp option - Someone: in wimax we already do dhcpinform for this. - Pete: did you deal with the home link issue Kent mentioned? - Someone: no - George: maybe we can do one MIP extension to send the DHCP server address to the MN, which can then the DHCPINFO message - Kent: That was one of the options but part of the initial requirement was to also support non-DHCP clients, but maybe as a compromise we can move on. - Raj: George’s approach seems to simplify this so I would propose we do something like that - Kent: Maybe there are some sequencing issues WRT PMIP. - Henrik: OK, so we do not get any of the host config docs yet but we are going to include the issue in the charter. Final Ham on EThernete Service indicated strong negative support 9. GRE Keying Update 5 min Parviz ======= TOTAL 1 hr, 50 min