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
