Date: Thu, Jul 29th 2010 Meeting Minutes: MIPv4 Working Group Attendees: MIP4 WG Chairs, Presenters, AD, Attendees (Jabber + In-room) 1. Status of current WG documents Chairs gave the status of the current working documents. The read-out is what is in the slides for each of the documents. Kent asked for clarification about RFC2006bis - no one in the mailing list seems to be interested. Suggestion about going outside the WG, asking e.g. SNMP people for feedback. 2. Generic Notification Discussion Henrik's presentation. Changes in -15 made due to comments from IESG. One of the major comments from IESG about "asynchronous messages" was that it could lead into a vendor-defined communications protocol => added limitations to contents. Main point to hear from WG: Too strict a limit on Message Definitions and considerations (Slide on Section 4) Sri: Idea from 3GPP - using their own messages. Henrik: Need either additional document or add in this document explicitly that vendor-specific extensions may be carried. Need to discuss with ADs. Kent: Generally in favor. SDOs might need interoperability, but individual vendors don't. Henrik: What's the way forward, then? Explicit extension for 3GPP or a more generic one? Sri: Mean including SDO-specific extensions to IETF standards? Henrik: No, but if there's already code that uses vendor-specific stuff it needs to be taken into account. Usage makes sense, question is how to go forward so that we benefit. Jari (AD): I think current proposal is fine. We just need to convince concerned ADs that their issues have been addressed. Would be better to prohibit vendor-specific stuff. Henrik: What's the timeline for 3GPP usage? Can they submit a different document? Sri: Not sure. Avi: This has already been used elsewhere, but I can't remember where specifically. Simon: Also used in Wimax. Henrik: Too little information right now to make decision. Jari: I think it'll be ok to list a specific case if there are references. ...presentation continues... 3. GRE Keying Draft Kent's Presentation. Draft in comment resolution phase. Sri: Is the explicit MUST discard on non-recognizable extensions needed since it's already RFC 3344. Henrik: Kent went back&forth many times on this [the discarding], now it's correct and referencing the RFC - that's why it's explicitly in the draft On FA operation: No way to force MN to set G-bit - but does it matter if FA-HA tunnel is different from MN-FA tunnel, so it could probably be overridden Sri: Will there be error? Kent: FA looks at local policy on how to handle this MN, and can add G-bit and extension by itself. Henrik: Your reasoning is good, but you should not write that "override" actually "sets" G-bit, keep them as separate contexts. "G2"-bit, not *same* bit. Parviz: G-bit setting is not going to change. The presence of the extension between FA and HA. Kent: There's some text about "overrides". Charles: What happens if HA doesn't honor the request? MN thinks things are ok but FA has added some stuff on it's own. Kent: If HA doesn't recognize, no problem. If HA recognizes, but doesn't allow, there's a specific error code that goes all the way to MN. Simon: What about other extensions? Kent: Any feature that is non-skippable encounters this issue. Should continue discussion offline. Can't have false positives where extension is skippable and nodes think differently on the network states. Pete: Would make people more confortable if you changed it so that if MN has 'D'-bit (co-located), FA is prohibited from adding the extension. In case where you are coloc but just registering through FA. Parviz, Kent: Agree ...Other comments? Simon: Non-skippable vs skippable - what's the real effect? Kent: We are just trying to enable specific services. Simon: Extensions are preferences that MN would like. Kent: No, they are requirements - you can't fall back to IPinIP. Avi: Reason we are doing this is overlapping IP addresses. Only way to provide service is GRE separation. Simon&Kent: It's all-or-nothing situation, no fallbacks, hence non-skippable. Henrik: FA is only going to add this extension when specifically getting the RADIUS response from the Home Network => Thus Home Agent should be able to support it since it's home network's RADIUS telling FA to add it. If it fails, it's a misconfiguration. Kent: Agree. Simon ok with this? Simon: Could this info be sent to FA before RRQ is even delivered? We just send the HA address? Kent: Is this 3GPP/Wimax issue? We can talk in mailing list. 4. Flow Binding Support for Mobile IPv4 Sri's presentation ...Consider a WG item? Pete: Will this work with multipath TCP? Sri: Flow is bound to a given path, since we want a synchronous flow. Pete: [intro on Mptcp] Sri: Probably not. This is essentially a set P-t-P links, but there's a policy on what flows are allowed on each link. Henrik: I think they work. One tunnel could be MPTCP tunnel. Pete: I thought MPTCP requires separate addresses for each endpoint. Here we have HoA for everything. Sri: Agree, thus not applicable. Jari: Whatever you do with this is below the normal MPTCP layer. Kent: What if the other end has multiple IP addrs? Sri: Then they are considered individual flows. Alex: Is there concept of default interface? We want to communicate policies, is it going to happen by single/arbitrary/all interfaces? Sri: Except for the UDP tunnel case, it doesn't really matter (In UDP there's a NAT consideration). Alex: We want reply to arrive on same interface where it was sent despite the policies. Sri: This is what happens. Alex: Ok, what about work in MEXT where you can encode multiple CoA's per HoA. Can we do this same thing here - multiple CoA's per tunnel? Sri: Not per tunnel. 1:1 relation with CoA and Tunnel. Alex: Tunnel is an encapsulation path. You can't go to 1:N. Henrik: Why do you want this? Alex: We don't use foreign agents. We have two tunnels in sequence to avoid ingress filtering - need to draw a picture. Henrik: Please do. Alex: I mean IPIP+GRE tunnel. Henrik: We have different terms. We'll wait for your diagram. Kent: Now that it's out, why is there is a double-tunnel. Sri: There isn't, not clear diagram. 5. Closing comments No comments.