[16:56:38] stevey joins the room [16:56:41] stevey leaves the room [19:59:26] wmhaddad joins the room [20:02:24] vidya joins the room [20:02:24] vidya leaves the room [20:02:39] mccap joins the room [20:04:27] DDD joins the room [20:04:59] Greetings I will be jabber scribing. [20:05:06] behcet.sarikaya joins the room [20:05:20] DDD leaves the room [20:05:20] Can everyone hear the audio stream? [20:05:25] satoru.matsushima joins the room [20:05:56] Rajeev is giving a review of bar bof & dinner meeting [20:06:49] 3 main areas: Multiple interface; localized routing; inter-tech handovers. [20:07:34] Dave Thaler joins the room [20:08:39] Who here is participating remotely and needs blow-by-blow coverage? [20:09:29] DDD joins the room [20:10:05] DDD leaves the room [20:10:13] Desire joins the room [20:12:40] Objective: identify if we have interest in proposed problems & working on solutions [20:13:30] Ground rules: assume 5213, pmip6 networks, no mip6 interaction, not a placeholder for NETLMM-related topics [20:14:10] Hesham Soliman speaking now [20:14:57] Jari speaking now. [20:17:44] http://www3.ietf.org/proceedings/09mar/slides/netext-0.ppt [20:20:20] Now on slide entitled "Ground Rules" [20:27:00] vidya joins the room [20:27:16] Now moving on to slides "Multiple Interface Support" [20:27:21] http://www3.ietf.org/proceedings/09mar/slides/netext-1.ppt [20:27:49] Vijay Devarapalli speaking. [20:29:26] Slide entitled "Scenario 1: Setting up Mobility Sessions on Demand" [20:29:44] jari joins the room [20:29:53] test [20:30:19] vidya, does the room work for you now? you seem to be in the room. [20:30:28] yes, just joined it 30 seconds ago [20:31:08] Scenario 2: Flow Mobility [20:32:41] Scenario 3 : Multiple interfaces and attachment to a new MAG [20:34:31] Slide, "Mailing List Discussion" [20:37:15] Elena joins the room [20:44:00] do we have a jabber scribe in the room? [20:44:06] Yes it's me. [20:44:12] Can you hear the audio? [20:44:28] I'm in another session.. so, cannot join the audio session [20:44:35] Ah. Ok. [20:44:43] would appreciate a jabber scribe of the Q&As if you could [20:44:50] We are discussing now whether mobile hosts need to be modified. [20:45:28] George T: assigning addresses to multiple interfaces. [20:45:40] Assigning the same IP address to 2 interfaces doesn't work. [20:45:44] okay, in case we are collecting opinions, my answer is no to modifying mobile hosts for network mobility [20:46:01] it defeats the purpose and the MN might as well do MIP6 [20:46:05] Can make it work by hiding multiple addresses from the normal IP stack. [20:46:42] Vidya do you want me to go to the mic? [20:47:14] please, if you could. But, it's ok if not [20:47:41] George T; we are modifying L2 of host instead of L3. [20:48:04] Kent: need to have some language to describe what can be changed. [20:48:22] Changing L2 is not within the IETF's charter [20:48:31] essentially, we are saying that it is somebody else's problem [20:49:15] DaveT: changes, proprietary or using RFCs [20:49:55] 16ng joins the room [20:50:12] Sri: virtual interface is host change? [20:50:28] DaveT: yes, it is not written in any RFC [20:50:40] Elena leaves the room: Replaced by new connection [20:50:40] Elena joins the room [20:50:48] not to mention, that it assumes a certain host architecture [20:51:26] I gave your comments on no modifications and L2 out of scope. [20:51:36] thanks [20:51:45] We are moving on to Marco Liebsch: PMIPv6 localized routing [20:51:59] http://www3.ietf.org/proceedings/09mar/slides/netext-3.ppt [20:52:39] Problem Description [20:52:55] Set up direct path MAG-to-MAG [20:53:02] bypass LMAs [20:53:36] Jari: hosts don't see any of this except perhaps for latency changes? [20:53:45] Marco: correct, we have to take care of the magic part. [20:54:10] Elena leaves the room: Replaced by new connection [20:54:11] Elena joins the room [20:54:31] Dave Thaler leaves the room [20:54:57] New slide: Reference Architecture [20:55:58] Reference Architecture (con't) [20:56:06] Dave Thaler joins the room [20:56:13] shared MAG, 2 LMAs [20:56:23] ML Discussion Summary [20:56:53] There was some feedback: [20:57:23] There is a single flag in RFC5213 to enable "localized routing" [20:57:36] No protocol between MAG/LMA to setup/tear down localized routing [20:58:35] Kent: 2nd slide: need context transfer. Handled as part of detection/setup? [20:58:41] Marco: don't specify in draft [20:58:57] Kent: when doing handoff, want to maintain optimized path. Captured in bullets? [20:59:05] Rajeev: yes, slide says during handover [20:59:35] Kent: on Reference Architecture, are we restricted to talking to another PMIPv6 node, or can be fixed node? [20:59:36] tsavo_work@jabber.org/Meebo joins the room [20:59:45] Rajeev: scope is within a PMIPv6 domain only. [21:00:15] Kent: on Reference Architecture (con't): With one MAG, doesn't this already work? [21:00:27] Rajeev: same MAG, but different LMAs possible. [21:00:32] which slide set are we in? [21:00:49] http://www3.ietf.org/proceedings/09mar/slides/netext-3.ppt [21:00:59] thx [21:01:26] 16ng leaves the room [21:01:30] Marco: we distinguished the case, but haven't looked at solution space yet. [21:02:11] Carlos: understanding of basic spec, current flag can only be used for optimizing service between PMIP MN and a non-PMIP MN [21:03:35] So if we are limited to PMIP MNs, we cannot use this flag. [21:03:50] Sri: not correct, just bypassing tunnel. [21:04:00] Elena leaves the room: Replaced by new connection [21:04:01] Elena joins the room [21:04:05] Carlos: wording of basic spec seems misleading. [21:04:22] Sri: focus on lack of signaling to enable forwarding so LMA can authorize that? [21:04:36] Rajeev: it's a protocol aspect. [21:04:55] Parviz: forward all traffic through localized routing, or is it selectively for low-latency traffic? [21:05:00] Rajeev: 2nd level questions. [21:05:04] Parviz: in the charter? [21:05:22] Rajeev: if we get chartered we can discuss whether to include in the charter. [21:06:01] Sung-din-yok: IPv4 support? [21:06:37] Rajeev: LMA to MAG signaling can include IPv4 address, so flow can be between 2 endpoints IPv4. It's possible. [21:08:10] Keran Palin: if it was just a host, you are VPNed onto home network, that is where you are assigned an address. If you put this on the network side, all the policy has to be there. Some assistance from the MN might help. [21:08:37] Rajeev: no change of interface here. Happens that 2 nodes attached to same MAG. [21:09:08] YunChun from Hitachi: clarify that MN might have multiple CNs, for each pair you need to do the localized routing? [21:09:12] Marco: yes [21:09:25] Rajeev: per mobile and CN pair, could even decide per-flow [21:09:42] YunChun: different routing to different CNs? [21:09:49] Rajeev: yes. [21:10:17] Now moving on to Suresh Krishnan, Inter-Tech Handoffs [21:10:19] http://www3.ietf.org/proceedings/09mar/slides/netext-2.ppt [21:10:21] http://www3.ietf.org/proceedings/09mar/slides/netext-2.ppt [21:10:27] :) [21:10:39] Reference Architecture [21:11:12] Legend: green for issues in MN, Blue for issues in the network [21:11:20] Access Selection [21:12:15] Handovers or simultaneous access [21:12:29] network cannot decide whether new attachment is part of a handover or wants simultaneous attachment. [21:12:40] Predictive Handovers [21:13:35] Interface Identifier Continuity: blue (network) issue [21:13:56] Elena leaves the room: Replaced by new connection [21:13:56] Elena joins the room [21:14:07] Implementation Specific Issues [21:14:29] A lot of OSes do not allow same IP address on multiple interfaces [21:15:28] Chung-wan: predictive handover, what is the timeframe? WAN & NAN, might stay on NAN for 1 hour. [21:15:51] Suresh: don't know. The point is we don't know whether handover is requested right then. [21:16:08] DaveT: blue titles, good point. [21:16:39] (Sorry I got the blue/green designations reversed) [21:17:30] DaveT: on the green slides, common LMA indicates some kind of trust? [21:17:45] Suresh: MAGs trust LMAs, may not trust each other. [21:17:55] DaveT: they have a common mediator, the LMA [21:17:57] what is Suresh's conclusion based on the issues? Is he saying that inter-tech handoffs should not be done with PMIP or something else? [21:18:09] I think he is just identifying issues. [21:18:46] yeah I think he's just pointing out the limitations today, not saying how you might solve them [21:18:57] Sri: same address on 2 interfaces: we support separate prefixes, not really the same [21:19:09] Suresh: if you assign different prefixes, it's not a handover. [21:19:21] PMIP today opens a new session, other sessions are screwed. [21:19:25] hmmm.. I agree with many/most of the issues and my take is that you don't want to solve these in PMIP at all - rather, an MN should be using MIP6 for inter-tech handoffs [21:19:40] I agree. [21:20:21] Suresh: new session, application has to re-start connections [21:20:39] Sri: even in MS, I can create a virtual interface, bind applications to that, decouple from physical interfaces. [21:21:01] Suresh: still need to be able to route packets outbound. Manual switch between interface A & interface B. [21:21:12] Sri: that's an outside requirement. [21:21:26] yes you can. But that's not what _apps_ do. and that's not what the _OS_ does. Hence it's a change to the host that is not in any RFC. [21:21:50] Hesham: agree with points, just want to add: 2 different AT, don't know about each other, don't know about utilization [21:22:05] it could be a new (virtual) link type which could be specified in an RFC or in IEEE for example [21:22:21] JuanCarlos: how can we bound what we are going to solve? Assume 802.21? Goes beyond scope of IETF. [21:22:39] Suresh: we aren't solving issues, just naming problems. [21:23:18] JC: defining interface to lower layers? [21:23:36] Rajeev: going into an area that we haven't discussed much. If we get to that point then we can discuss it. [21:23:47] Elena leaves the room: Replaced by new connection [21:23:47] Elena joins the room [21:24:00] TelemoMelia: numbers, order of seconds when you do this break. Especially DHCP it doesn't work. [21:24:12] Suresh: that's why you need DNA. [21:24:46] GregDaley: There is Advanced Sockets API which reveals the interface index. Have to know it goes to the virtual ifindex when you bind your application. [21:24:58] That's not how my host OS works today. [21:25:06] Suresh: netlink, etc, let's not go there. [21:25:48] if you have a virtual interface, that IS how the host OS works today. But the OS doesn't create such a virtual interface today. [21:26:03] GeorgeT: agree with issues. We saw Vijay's multihoming presentation. Would have expected BOF to take issues to be worked on, then show some hope for solving them. [21:26:15] (at least not the OS that was mentioned by the speaker... windows) [21:26:19] Suresh: can deide whether we are going to solve handovers in all cases. [21:26:40] Rajeev: no cut-and-dried way of solving them. Hope you are not saying problems are hopeless. [21:26:58] GeorgeT: this is a problem statement, Vijay's presentation was not associated with these problems. [21:27:30] Kent: also trying to differentiate between multi-interface and multi-access. Another detail is multi-radio vs. single radio. [21:27:54] Suresh: some issues become irrelevant when you only have one radio. E.g., you won't have predictive handover. [21:28:24] Kent: trying to be as broad as possible. Comment that some issues are single radio issues might want to be added. [21:28:52] Raj: solution space will be what you can achieve given device characteristics. It is too premature to consider assumptions about multi/single interfaces. [21:29:08] Kent: not getting into solution space, just want to make sure all issues are identified. [21:30:06] Elena leaves the room: Replaced by new connection [21:30:06] Elena joins the room [21:30:20] Rajeev: multi-iface support 3 things: 1. ability to create multiple mobility sessions (maybe just add identifier). 2. Assume 2 interfaces available, split flows across different interfaces. Suresh's problems are quite specific to inter-technology handovers. [21:30:44] Suresh: George seemed to be saying that problems were presented differently. [21:30:50] are we talking about multiple sessions on the same _virtual_ interface (1 per physical interface) or multiple on the same physical interface? [21:31:18] KenanPalin: another access network, host can decide not to make new connection to break existing connection [21:31:35] Suresh: that's a policy profile (ala what Sri would say) [21:31:48] lixia joins the room [21:31:53] satoru.matsushima leaves the room [21:31:54] Premec: Bulk re-registrations. [21:32:17] http://www3.ietf.org/proceedings/09mar/slides/netext-5.ppt [21:32:33] Slide 1: "Bulk Re-registrations" [21:33:33] Slide 2: signaling for multiple sessions [21:33:44] Slide 3: Proposal: bulk re-registration. [21:34:07] wmhaddad leaves the room: Computer went to sleep [21:34:39] ML discussion summary [21:35:08] New presentation: Initial LMA Selection/Discovery [21:35:21] http://www3.ietf.org/proceedings/09mar/slides/netext-4.ppt [21:35:31] Premec on behalf of Jouni [21:36:01] Efficient in-band solution for PMIP to assign LMA address. Propose when MAG sends initial PDU, it should be redirected from one LMA to another LMA. [21:36:08] No reliance on AAA or DNS. [21:37:18] Kent: Support LMA selection. Good issue to address. On solution space: anycast address. (won't get into it. It is a good problem to solve). [21:37:51] Kent: on bulk re-registration: MIP4 has infinite lifetime. Bulk signaling is not really needed in quite some cases. Better ways to do re-registration or remove need for re-registration. [21:38:00] Premec: agree, possible to remove completely. [21:38:08] Sri: LMA selection is very critical. [21:38:25] Sri: bulk re-reg, important parameter is how to identify group that you are re-registering. [21:38:40] Premec: can talk about solutions, this is just problem. [21:38:49] Hidetoshi: support LMA selection. [21:39:05] Jonne: would like to support both of these. [21:39:44] Rajeev: summarizing before open-mic discussion. [21:39:47] the 3 areas [21:40:08] One issue: how do you take an address from one interface and assign it to another interface [21:40:09] Chip Sharp joins the room [21:40:38] There seem to be solutions without protocol changes. It is a fundamental problem. [21:40:54] In multiple interface problem statement, interfaces are active simultaneously. [21:41:09] For localized forwarding: suresh brought up issues that come up in inter-tech handovers. [21:41:43] Raj is opening up the floor for comments/questions prior to taking opinions. [21:42:23] Greg Daley: even if you had virtualized interfaces, you still have problems of interface selection on wireless host and there is no predictability. No way to feed back to device whether it has a valid problem. Doesn't seem like a tractable problem. [21:42:35] Rajeev: so how do you move IP address to another interface? [21:42:55] GD: that is dangerous to applications, they might be attached to physical interface. It is a conundrum. [21:43:25] Sri: don't agree. We need an info doc on how to support inter-tech handoff e.g., virtual interfaces. No changes to stack, but document needs to be there. [21:43:58] Hesham: we are having all these discussions about whether to change host or not, goes to question of whether this WG is needed at all. [21:44:20] Hesham: might go down path where we require changes on L2, plus protocol messaging. [21:44:27] Hesham: other path is L3, that should be MIP. [21:44:44] Hesham: don't see a way to solve these problems without doing one or the other. [21:44:56] Hesham: answer to the question is don't do it with PMIPv6. [21:45:03] Rajeev: that's why we're talking here. [21:45:25] Raj: people here believe we can do inter-tech handover. [21:45:53] Rajeev: if we need to document how something is supposed to work, we can do that. Some people want to write something saying how it can be done. [21:46:26] GeorgeT: 2 problems: you say it might be done, but only in a closed system defined by one SDO. Different from solving in IETF for any link-layer [21:46:50] GeorgeT; number 2, seemed to separate inter-technology from multi-homing. That doesn't work. [21:47:06] Rajeev: didn't mean they were strictly disjoint, but for this presentation we listed them separately. [21:47:17] GeorgeT: inter-tech and multihoming are the same thing. [21:47:24] Rajeev: noted, some people might not agree [21:48:18] DaveT: localized routing & bulk re-registration are great and should be done somewhere. On the issue of how to deal with other issues: don't move from iface to iface, but solve it a different way. Bind addresses to physical interfaces under virtual interface. [21:48:55] DaveT: relationship to 802.21. L2, we don't do L2. Shouldn't do anything that is exactly the same space as IEEE. If 802.21 could solve our problems, then we don't need to worry about it. [21:49:05] Rajeev: that was specific to AN selection. [21:49:20] DaveT: inter-tech handovers, that is 802.21 from my reading of the web page. [21:49:50] DaveT: iface identifier related to MAC addresses. Talking about MAC on a virtual interface. Need to worry about MAC address preservation. [21:50:16] DaveT: if we believe it is easiest to solve at L2, we can send them a liaison. [21:50:20] Rajeev: agreed. [21:51:04] JamesKempf: the only work that makes sense is Marco's on local routing. We started this work, there was no intent that MN would ever be completely cut out of mobility. There would always be cases, should be Mobile IPv6. [21:51:18] Jari: like RO and bulk registration and LMA discovery. [21:51:41] Jari: wrt multi-homing and handover stuff: agree there are problems. Accurate description of what can/cannot be done today. [21:52:12] Jari: there are some limitations, we might or might not want to solve those limitations. LMA is for certain things, sometimes you need MN involvement and client mobility. [21:52:15] note jabber scribe reversed sense of one of my points: should be "_DON'T_ bind addresses to physical interfaces under virtual interface, _bind them to the virtual interface_". Just wanted this correction in the jabber logs for clarity. [21:52:24] Apologize. [21:52:30] np, thanks much for scribing! [21:53:02] Raj: work on multi-homing problem separately. Now we are trying to address other scenarios that were pushed out of base protocol. [21:53:14] Jari: ok, we need to make a decision on whether we want to solve these problems. [21:54:10] Vidya: multi-homing, increase scope of base draft, hosts with multiple interfaces don't break down with PMIP. Talking here is about handling multi-homing within the PMIP protocol. PMIP was not designed for that. It was about local mobility. As IETF we were not recommending any changes to MN. [21:54:29] Rajeev: some people believe we should re-examine. Are you saying we shouldn't? [21:54:59] Vidya: multi-homing and multi-tech cannot be solved without MH involvement. As IETF we have protocols that work, we should be using them. [21:55:15] Parviz: problem statement/problem space, different solutions, not what IETF is about. [21:55:28] Rajeev: trying to investigate whether we can solve these problems. [21:56:02] Vijay: want to re-iterate that. There are folks that claim multihoming cannot be solved without MN modifications. That's not true. It's important to investigate scenarios and see for sure. [21:56:10] lixia leaves the room [21:57:06] Marco: inter-tech handover, document about what host needs to do to move IP addresses: not the right term, assign home network prefix, LMA should still anchor the home network prefix. It's not moving the IP address, we have to move the suffix. Talking about OS specifics is difficult to do. Not the role of netext. [21:57:42] Sri: confusion: talking about same/separate interfaces not germane: session continuity. We are missing some requirements. [21:58:12] Raj: PS is how to maintain session continuity when PMIP host moves from one interface or Access Tech to another. [21:58:23] mic: is important work, we should look at it. [21:58:45] Rajeev: some topics are controversy-free. Want to get some impression on multi-interface etc. [21:58:52] How many would like to look at problem? [21:59:05] Multiple iface support for PMIPv6? [21:59:36] Some hands. [21:59:44] How about not? [21:59:50] Some smaller number of hands. [21:59:57] GeorgeT & Davet: bad question. [22:00:13] Rajeev: how many people want to look into solving this problem in the IETF context. [22:00:26] How many people think we should not do that? [22:00:36] 20 hands vs. 8 hands. [22:01:06] Hesham: PS saying this cannot be done with PMIPv6 today, different question from whether we can do this with MIPv6 [22:01:15] Vidya: IETF has a solution, why is it not applicable? [22:01:24] Rajeev: IETF had a solution, then we did PMIP. [22:01:33] Vidya: maybe that was a bad idea but it's done. [22:01:38] Vidya: why PMIP now? [22:01:50] Rajeev: because we are going with PMIP. Need to have certain features and functions. [22:02:09] Marcello: one of the reasons for doing PMIP is no host changes, not no protocol changes. That is what is being mixed up here. [22:02:25] Jari: we are mixing up problem statement and solution space. (PMIP vs. c-MIP). [22:02:37] Jari: should we do CMIP? [22:03:10] Vidya: another clarification: client IP mobility, network mobility with multihoming is not without client involvement. [22:03:31] Jari: I am talking about client IP mobility, I agree that if we do PMIP we may still need client changes. [22:03:48] Jari: asking whether CMIP? [22:03:50] 12 hands. [22:04:02] vidya leaves the room [22:04:04] +1 [22:04:05] Jari: extend PMIP to do this, including host changes? [22:04:06] behcet.sarikaya leaves the room [22:04:25] about the same number of hands. [22:04:32] Jari: need more discussion on the list [22:04:37] Goodbye. [22:05:05] mccap leaves the room [22:06:35] tsavo_work@jabber.org/Meebo leaves the room [22:10:07] Elena leaves the room: Computer went to sleep [22:10:24] Desire leaves the room [22:11:13] lixia joins the room [22:11:23] lixia leaves the room [22:12:20] Dave Thaler leaves the room [23:11:35] Chip Sharp leaves the room