Hi Saumya, Thanks for your comments. We submitted Rev. 10 of the draft as follows.
Regards, Behcet A new version of I-D, draft-sarikaya-nvo3-vmm-dmm-pmip-10.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-sarikaya-nvo3-vmm-dmm-pmip Revision: 10 Title: Virtual Machine Mobility Protocol for Overlay Networks Document date: 2016-03-21 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-vmm-dmm-pmip-10.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-10 Diff: https://www.ietf.org/rfcdiff?url2=draft-sarikaya-nvo3-vmm-dmm-pmip-10 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 Network Virtualization Authority (NVA)-Network Virtualization Edge (NVE) protocol to update Address Resolution Protocol (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 On Fri, Mar 18, 2016 at 3:00 PM, 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-pmip >>>>>>>-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-08 >>>>>>> >>>>>>> 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
