I support this draft as it captures generic content on VM mobility across all overlay encapsulations discussed under NVO3
Thanks Saumya. On 3/19/16, 1:30 AM, "Saumya Dikshit (sadikshi)" <[email protected]> wrote: >Hi Authors of "draft-sarikaya-nvo3-vmm-dmm-pmip”, > >Please find following comments (apology for pitching in late): > >>>>> 1. Introduction >>>>> These networks are organized as one large Layer 2 network >>>>>geographically distributed in several buildings. > >MSDC’s deployment can span across L2-boundries; a typical NVE can function >as L3-gateway for inter-L2-domain connectivity (routing across bridging >domains). >This may be a typical deployment for a web-OTT (east-west traffic); >transaction handling across front-end server, storage and compute >elements. > >>>>> 4. Overview of the Protocol >>>> >>>>> In a Layer-2 based data center approach, virtual machine moving to >>>>>another server does not >>>>> change its IP address. >Does this literature also handles cases for VM movement across >L3-boundries, though not typical ? > >>>>> In a Layer-2 based data center approach, virtual machine moving to >>>>>another server does not >>>>> change its IP address. > >There are potential cases where IP addresses is re-allocated (in same >subnet), >via a DHCP server serving the new POD (may be across geographical >boundaries). >Needs to be categorically captured that these cases should be handled >with/without assumptions. > >>>>> Reverse ARP (RARP) which enables the host to discover its IPv4 >>>>> address when it boots from a local server [RFC0903] is not used by >>>>> VMs because the VM already knows its IPv4 address. IPv4/v6 address >>>>> is assigned to a newly created VM, possibly using Dynamic Host >>>>> Configuration Protocol (DHCP). > >There are vendor deployments (diskless systems or without configuration >files) where in VM-users (end-user clients) ask for the same MAC upon >migration, >and it speak up with RARP sending out the old MAC address and looking for >an IPv4/IPv6 address allocation. >Though procedure should be identical with respect to triggering NVE-NVA >communication for GARP case; but in this case only MAC learning >is performed by new NVE and informed to NVA on a identifying the connected >host with RARP packet (to ensure backward compatibility to >legacy/brownfield deployments). >NVA can negotiate/update Old NVE mappings (with MAC address as the key) >and re-assign the same IPv4-address to moved VM by asking, new NVE behind >which VM has migrated >to send a RARP response. This can be paraphrased if its not okay with the >authors. > > >Thanks >Saumya. > >On 3/15/16, 10:01 PM, "Behcet Sarikaya" <[email protected]> wrote: > >>Hi Saumya, >> >>On Tue, Mar 15, 2016 at 9:15 AM, Saumya Dikshit (sadikshi) >><[email protected]> wrote: >>> Hi Behcet, >>> >>> Are you looking for a disclaimer or extensions to handle RARP. >>> >> >>We have added one paragraph on RARP, 5th paragraph in Section 4. >>It is basically saying that RARP which is obsolete has been replaced by >>DHCP. >> >>If you have any edits on this or other parts of the draft let me know. >>Otherwise we believe the draft is in good shape and we ask an adoption >>call before IETF 95. >> >>Regards, >> >>behcet >>> >>> Thanks >>> Saumya. >>> >>> On 3/9/16, 4:44 AM, "Behcet Sarikaya" <[email protected]> wrote: >>> >>>>On Mon, Mar 7, 2016 at 5:18 AM, Saumya Dikshit (sadikshi) >>>><[email protected]> wrote: >>>>> Hi Andrew, >>>>> >>>>> VM speaking up using RARP, is discounted as one of the potential >>>>>cases ? >>>>> >>>> >>>>Saumya, please suggest some text. >>>> >>>>Regards, >>>> >>>>Behcet >>>>> Thanks >>>>> Saumya. >>>>> >>>>> From: "Andrew G. Malis" <[email protected]> >>>>> Date: Monday, March 7, 2016 at 4:02 PM >>>>> >>>>> To: sadikshi <[email protected]> >>>>> Cc: "B. Khasnabish" <[email protected]>, Matthew Bocci >>>>> <[email protected]>, "[email protected]" <[email protected]>, >>>>>Benson >>>>> Schliesser <[email protected]>, sarikaya <[email protected]>, >>>>>Alia >>>>>Atlas >>>>> <[email protected]> >>>>> Subject: Re: [nvo3] Fwd: New Version Notification for >>>>> draft-sarikaya-nvo3-vmm-dmm-pmip-08.txt >>>>> >>>>> Saumya, >>>>> >>>>> Either you¹re using static IP addresses, in which case this is a >>>>> configuration error and needs to be manually corrected, or you¹re >>>>>using >>>>> dynamic IP addresses, in which case if the VM receives a GARP reply >>>>>because >>>>> of a duplicated IP address, it then uses DHCP to get a new one. >>>>> >>>>> Cheers, >>>>> Andy >>>>> >>>>> >>>>> On Mon, Mar 7, 2016 at 1:45 AM, Saumya Dikshit (sadikshi) >>>>> <[email protected]> wrote: >>>>>> >>>>>> Hi Andrew, >>>>>> >>>>>> Is it assumed that IP address will be known and not dynamically >>>>>> re-assigned and all VM¹s are capable of sending out GARP at >>>>>>boot-up. >>>>>> I agree RARP may not be new, but I think still used. >>>>>> Whats happens in a case where VM is migrated to DC-network (may be >>>>>>across >>>>>> geographies and NVO domains) where the IP is already assigned >>>>>> to another VM/entity >>>>>> >>>>>> Thanks >>>>>> Saumya. >>>>>> >>>>>> From: "Andrew G. Malis" <[email protected]> >>>>>> Date: Monday, March 7, 2016 at 2:12 PM >>>>>> To: sadikshi <[email protected]> >>>>>> Cc: "B. Khasnabish" <[email protected]>, Matthew Bocci >>>>>> <[email protected]>, "[email protected]" <[email protected]>, >>>>>>Benson >>>>>> Schliesser <[email protected]>, sarikaya <[email protected]>, >>>>>>Alia >>>>>>Atlas >>>>>> <[email protected]> >>>>>> Subject: Re: [nvo3] Fwd: New Version Notification for >>>>>> draft-sarikaya-nvo3-vmm-dmm-pmip-08.txt >>>>>> >>>>>> Saumya, >>>>>> >>>>>> No, Gratuitous ARP is used to update the other ARP tables when a VM >>>>>>moves. >>>>>> RARP was used to request your own IP address when you don¹t know it, >>>>>>but is >>>>>> obsolete, and anyway, the VM already knows its IP address (see >>>>>>section >>>>>>8 in >>>>>> the draft). >>>>>> >>>>>> Cheers, >>>>>> Andy >>>>>> >>>>>> >>>>>> On Sun, Mar 6, 2016 at 9:31 PM, Saumya Dikshit (sadikshi) >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Hello Authors of draft-sarikaya-nvo3-vmm-dmm-pmip, >>>>>>> >>>>>>> Do we need to take care of cases in which VM speaks with >>>>>>>Reverse-ARP >>>>>>>and >>>>>>> not Gratuitous-ARP ? >>>>>>> >>>>>>> Thanks >>>>>>> Saumya. >>>>>>> >>>>>>> >>>>>>> From: "B. Khasnabish" <[email protected]> >>>>>>> Date: Monday, March 7, 2016 at 7:13 AM >>>>>>> To: Matthew Bocci <[email protected]>, >>>>>>>"[email protected]" >>>>>>> <[email protected]>, Benson Schliesser <[email protected]> >>>>>>> Cc: sarikaya <[email protected]>, Andrew Malis <[email protected]>, >>>>>>>Alia >>>>>>> Atlas <[email protected]> >>>>>>> Subject: [nvo3] Fwd: New Version Notification for >>>>>>> draft-sarikaya-nvo3-vmm-dmm-pmip-08.txt >>>>>>> >>>>>>> >>>>>>> Dear All, >>>>>>> >>>>>>> We have addressed all of the outstanding issues, comments, >>>>>>> and suggestions in the latest version (ver-08) of this >>>>>>> draft on Virtual Machine Mobility >>>>>>> (VMM, >>>>>>>https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-vmm-dmm-pmip/) >>>>>>> and look forward to your support for WG adoption and subsequent >>>>>>> publication. >>>>>>> >>>>>>> Many thanks in advance. >>>>>>> >>>>>>> Best. >>>>>>> >>>>>>> Bhumip >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: <[email protected]> >>>>>>> Date: Thu, Mar 3, 2016 at 7:28 PM >>>>>>> Subject: New Version Notification for >>>>>>> draft-sarikaya-nvo3-vmm-dmm-pmip-08.txt >>>>>>> To: Bhumip Khasnabish <[email protected]>, Linda Dunbar >>>>>>> <[email protected]>, Behcet Sarikaya <[email protected]>, >>>>>>>Frank >>>>>>>Xia >>>>>>> <[email protected]>, Linda Dunbar <[email protected]> >>>>>>> >>>>>>> >>>>>>> >>>>>>> A new version of I-D, draft-sarikaya-nvo3-vmm-dmm-pmip-08.txt >>>>>>> has been successfully submitted by Behcet Sarikaya and posted to >>>>>>>the >>>>>>> IETF repository. >>>>>>> >>>>>>> Name: draft-sarikaya-nvo3-vmm-dmm-pmip >>>>>>> Revision: 08 >>>>>>> Title: Virtual Machine Mobility Protocol for Overlay >>>>>>>Networks >>>>>>> Document date: 2016-03-03 >>>>>>> Group: Individual Submission >>>>>>> Pages: 11 >>>>>>> URL: >>>>>>> >>>>>>>https://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-vmm-dmm-pmi >>>>>>>p >>>>>>>-0 >>>>>>>8.txt >>>>>>> Status: >>>>>>> https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-vmm-dmm-pmip/ >>>>>>> Htmlized: >>>>>>> https://tools.ietf.org/html/draft-sarikaya-nvo3-vmm-dmm-pmip-08 >>>>>>> Diff: >>>>>>> >>>>>>>https://www.ietf.org/rfcdiff?url2=draft-sarikaya-nvo3-vmm-dmm-pmip-0 >>>>>>>8 >>>>>>> >>>>>>> Abstract: >>>>>>> This document describes a virtual machine mobility protocol >>>>>>>commonly >>>>>>> used in data centers built with overlay-based network >>>>>>>virtualization >>>>>>> approach. It is based on using a NVA-NVE protocol to update ARP >>>>>>> table or neighbor cache entries at the NVA and the source NVEs >>>>>>> tunneling in-flight packets to the destination NVE after the >>>>>>>virtual >>>>>>> machine moves from source NVE to the destination NVE. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission >>>>>>> until the htmlized version and diff are available at >>>>>>>tools.ietf.org. >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>>_______________________________________________ >>>>nvo3 mailing list >>>>[email protected] >>>>https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
