Subject: [nvo3] draft-sarikaya-nvo3-vmm-dmm-pmip-00.txt

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 18 Feb 2013 15:12:12 -0600

Hello all,

Linda and I submitted a VM Mobility solution draft based on the issues
described in

draft-ietf-nvo3-vm-mobility-issues

would be delighted to hear your comments.

Behcet

A new version of I-D, draft-sarikaya-nvo3-vmm-dmm-pmip-00.txthas been
successfully submitted by Behcet Sarikaya and posted to theIETF
repository.Filename:        draft-sarikaya-nvo3-vmm-dmm-pmipRevision:
 00Title:           Virtual Machine Mobility Protocol Using Distributed
Proxy Mobile IPv6Creation date:   2013-02-18Group:           Individual
SubmissionNumber of pages: 14URL:
http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-vmm-dmm-pmip-00.txtStatus:
         http://datatracker.ietf.org/doc/draft-sarikaya-nvo3-vmm-dmm-pmipHtmlized:
       http://tools.ietf.org/html/draft-sarikaya-nvo3-vmm-dmm-pmip-00

Abstract:
   This document specifies a new IP level protocol for seamless virtual
   machine mobility in data centers.  Source Hypervisor registers the
   newly created virtual machine with the centrally available management
   node.  When the virtual machine moves to the destination Hypervisor,
   the destination Hypervisor updates the virtual machine record in the
   management node.  Management node sends registration message to all
   previous source Hypervisors in order to direct the ongoing traffic to
   the destination Hypervisor.  Cold and hot virtual machine mobility
   are achieved using dynamic domain name system update and host routes.
   Both intra data center and inter data center hot virtual machine
   mobility solutions are presented.

The IETF Secretariat

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 18 Feb 2013 23:30:22 -0500

On Mon, Feb 18, 2013 at 4:12 PM, Behcet Sarikaya <[email-masked]> wrote:
> A new version of I-D, draft-sarikaya-nvo3-vmm-dmm-pmip-00.txt

I have read your draft and I have a number of comments.

You indicate a BGP-based mechanism for inter-datacenter IP mobility.
Your draft specifies that, "UPDATE message contains one or more ORIGIN
path attributes containing the address prefix values in IPv4 or IPv6
of the VM when it was at the source hypervisor."

I think you are confused because the ORIGIN attribute contains one of
three possible values: IGP, EGP, or INCOMPLETE.  These are commonly
expressed in router CLI as "I", "E", or "?" and are a component used
in the BGP best-path selection algorithm.  They do not identify an
originating router or node for a prefix.

You propose the management control-plane will send routing update
messages to the "old hypervisor" ToR or its default router, and also
send messages to the old hypervisor itself, causing that old
hypervisor to install host routes.  Why?

How do you know the old hypervisor's ToR or gateway will be capable of
forwarding packets to the new hypervisor?  If the network contains
more than one router, routing information must be propagated to some
additional routers, even in absence of a multiple-datacenter scenario,
if the "source" and "destination" hypervisors do not share a common
default gateway.

A person could read this and wonder whether the authors have any
experience with, or understanding of, IP networks containing more than
one router.
-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 20 Feb 2013 18:05:01 -0500

Behcet:

After reading your draft, I think you are simply trying to insert IPv6 or
IPv4 or other NLRI prefixes in the IGP or BGP. 
Do I understand this correctly? 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff
Wheeler
Sent: Monday, February 18, 2013 11:30 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] draft-sarikaya-nvo3-vmm-dmm-pmip-00.txt

You indicate a BGP-based mechanism for inter-datacenter IP mobility.
Your draft specifies that, "UPDATE message contains one or more ORIGIN path
attributes containing the address prefix values in IPv4 or IPv6 of the VM
when it was at the source hypervisor."

I think you are confused because the ORIGIN attribute contains one of three
possible values: IGP, EGP, or INCOMPLETE.  These are commonly expressed in
router CLI as "I", "E", or "?" and are a component used in the BGP best-path
selection algorithm.  They do not identify an originating router or node for
a prefix.

You propose the management control-plane will send routing update messages
to the "old hypervisor" ToR or its default router, and also send messages to
the old hypervisor itself, causing that old hypervisor to install host
routes.  Why?

How do you know the old hypervisor's ToR or gateway will be capable of
forwarding packets to the new hypervisor?  If the network contains more than
one router, routing information must be propagated to some additional
routers, even in absence of a multiple-datacenter scenario, if the "source"
and "destination" hypervisors do not share a common default gateway.

A person could read this and wonder whether the authors have any experience
with, or understanding of, IP networks containing more than one router.
--
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts
_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3