Liyizhou@ . ï½ Recap the proposal ï½ Questions from last meeting and answers
Embed Size (px)
Transcript of Liyizhou@ . ï½ Recap the proposal ï½ Questions from last meeting and answers
- Slide 1
email@example.com Slide 2 Recap the proposal Questions from last meeting and answers Slide 3 M M bit: 1 = migrated VDP request 0 = newly started VDP request Slide 4 to facilitate switch port configuration and restore the states DHCP snooping based filtering Multicast group join Slide 5 Problems: ToR port snoops DHCPACK and binds IP/MAC/port to filter the following traffic. When VM moves, VM wont resend DHCP request and hence new port wont listen any DHCPACK. Therefore filter wont be enabled on new port. NIC DCN VM Server vSwitch DHCP Server TOR 15 2 3 3. DHCP Ack 5. DHCPACK 4 4. DHCP Snooping and set up IP/MAC /port filter 1. DHCP request 2. DHCP Request VM Server vSwitch migration 6 7 7. DHCP Snooping based filter on new port. How? 6. VM migration. Note DHCP Discover and DHCP Offer exchanges are ignored in picture Slide 6 With M bit: trigger some standard DHCP in-band mechanism to be used. E.g. DHCP leasequery NIC VM Server vSwitch DHCP Server TOR 1 5 2 3 2. VDP request w/ M bit 4 VM Server vSwitch migration 6 1. VM migration. 3. DHCP leasequery 4. DHCP Ack 5. DHCP Snoops ACK and set up IP/MAC /port filter 6 VDP response Slide 7 Problems: VM1 sends IGMP join so that ToR would have a multicast membership list including VM1 on certain port for certain multicast group address. After migration, VM1 wont resend IGMP join as it has no awareness of movement of itself. Multicast membership list wont have VM1s info enabled on new port until vm1 receives and responds the general IGMP query from IGMP querier. NIC VM Server vSwitch TOR NIC VM Server vSwitch 3 vm migration TOR GW 1 IGMP JOIN2 multicast group traffic IGMP 4. New port joins VMs multicast groups. How? 1 2 GW IGMP querier 3 Slide 8 With M bit: trigger some standard IGMP in-band mechanism to be used. E.g. new ToR port fakes IGMP query to VM NIC VM Server vSwitch TOR NIC VM Server vSwitch 1.VM migration TOR GW 3. IGMP query IGMP 4. IGMP report 1 2 GW IGMP querier 3 2. VDP request w/ M bit 4 Slide 9 Q: Without M bit, we can still use standard VDP associate to trigger the DHCP/IGMP behavior we want. A: No, because of the timing. M bit (migration completes) is a signal to do the triggering at the right time. Conventional VDP is not strictly coupled to VMs state. (see next slide). Wrong timing implies the high possibility to get wrong information. Slide 10 Uncertain time duration old EVB Station old EVB Bridge new EVB Bridge new EVB Station assoc_req assoc_rsp Dataframe VSI power on Start migration assoc_req assoc_rsp Dataframe Migration completes assoc_req w/ M-bit assoc_rsp Trigger DHCP/IGMP procedures VSI can still join/leave multicast group and update its DHCP lease Uncertain time duration Conclusion: M-bit indicates the completion of the migration which is the right time to trigger DHCP/IGMP procedures described before pre-assoc/assoc can be sent at any time, it is not coupled to the migration state of VSI. And it is also used for keepalive. Slide 11 Q: Can hypervisor perform like DHCP relay/IGMP relay to send the DHCP leasequery and IGMP query instead of bridge? A: Hypervisor could do that but we believe it would be better to put all the functions on adjacent bridge for the following reason Bridges have already implemented the features like DHCP relay or IGMP relay/proxy. There is little extra functions required. While hypervisors are not. There may come more real time configurations/provisions other than DHCP/IGMP in future. It is tedious to have hypervisor add features on demands of network requirements every time. Slide 12 Questions from last meeting (3) Q: Can hypervisor know the state of VM? A: Yes. Take VMWares vSphere as example. It has the event to indicate the start and end of a migration with event type VmBeingHotMigratedEvent and VmMigratedEvent. Hence it is considered implementation practical for hypervisor being able to set M bit at right time.