[00:39:46] Pete McCann joins the room [00:55:02] sukmoonlee joins the room [00:55:51] sukmoonlee leaves the room [01:00:02] sukmoonlee joins the room [01:00:37] sukmoonlee leaves the room [01:05:10] Hyong-Jong Paik joins the room [01:17:04] Pete McCann leaves the room [01:17:35] Pete McCann joins the room [01:21:30] Hyong-Jong Paik leaves the room [01:22:25] adrianfarrel joins the room [01:23:12] becarpenter joins the room [01:23:51] is anyone here not in the physical room? [01:24:02] Yes me. [01:25:05] feel free to request me to channel for you [01:25:27] thanks - still in listen mode [01:34:11] Next talk will be http://www.ietf.org/proceedings/79/slides/armd-6.ppt, slides are already on the screen [01:49:18] Dave Thaler joins the room [01:50:17] http://www.ietf.org/proceedings/79/slides/armd-2.pdf [01:53:11] bhoeneis joins the room [01:58:17] I thought that the assumption was VM retains the same MAC and IP before and after move. Why do we need to re-run ARP? We need to update the spanning tree, which we can do with an L2 XID frame, but the IP-to-MAC mapping stays the same. No? [02:01:41] the MAC-to-switch-port mapping changes [02:02:12] Sure, that's a matter for the ethernet L2 switching table, not the IP-to-MAC mappings in other hosts, right? [02:02:43] yes, although my understanding is that it's populated based on the ARPs (and possibly data packets) [02:03:26] not sure though [02:03:41] I believe it's populated by any data packet. I don't understand why we are tying this so closely to ARP. The XID frame is used in 802.11 for exactly this purpose: the AP sends it on behalf of the host when it detects a new attachment. Hypervisor could do the same thing. [02:05:01] yes [02:05:04] I agree [02:06:54] many would like to optimize the broadcast distribution based on that table, to only go to the port(s) with the target IP, but that's orthogonal to re-reruning ARP when you move as you say. [02:07:46] I guess people are putting logic in switches to filter the ARPs so they go only to the places that need to see them. Those kinds of tables might need to be handled carefully upon mobility. [02:10:10] Yes. Bring back the DEC Gigaswitch! [02:15:21] http://www.ietf.org/proceedings/79/slides/armd-4.pdf [02:18:37] Doesn't mobility break this, assuming MAC/IP stay the same after movement? It is like debating PI vs. PA with multihoming. [02:22:05] adrianfarrel leaves the room [02:25:48] http://www.ietf.org/proceedings/79/slides/armd-7.ppt [02:37:04] Adobe says the PDF is damaged and refuses to open. [02:44:38] http://www.ietf.org/proceedings/79/slides/armd-8.ppt [02:44:59] we skipped the broken PDF! [03:12:45] The hypervisor could contain a NAT with mobile router protocols. [03:16:51] becarpenter leaves the room: offline [03:32:35] bhoeneis leaves the room [03:32:48] Thanks! [03:32:52] Pete McCann leaves the room [03:47:35] Dave Thaler leaves the room [04:38:06] bhoeneis joins the room [04:42:35] bhoeneis leaves the room [04:42:47] bhoeneis joins the room [05:02:35] Dave Thaler joins the room [05:03:48] Dave Thaler leaves the room [05:06:36] bhoeneis leaves the room