Subject: [nvo3] 答复: Comments on draft-ietf-nvo3-overlay-problem-statement

From: Qin Wu <[email-masked]>
Date: Tue, 9 Apr 2013 08:02:17 +0000

Hi, Eric:
Sorry for my missing your reply for quite a long time.
I believe you understand my concern. However when I revisit the section3.7 of PS draft, I feel even confusing, it said:
“
   The optimal forwarding problem applies to both outbound and inbound
   traffic.  For outbound traffic, the choice of outbound router
   determines the path of outgoing traffic from the VM, which may be
   sub-optimal after a VM move.  For inbound traffic, the location of
   the VM within the IP subnet for the VM is not visible to the routers
   beyond the virtual network.  Thus, the routing infrastructure will
   have no information as to which of the two externally visible
   gateways leading into the virtual network would be the better choice
   for reaching a particular VM.
”
My point is multi-homing issue or one network endpoint is connecting to one VN through multiple first hop network devices
may complicate optimal forwarding problem but seems not the basic problem for optimal forwarding.
The basic problem for optima forwarding is the case each VN has one first hop network device or egress router.

For inbound traffic, even you only have one first hop network device that connect source network endpoint to one source VN,
The location of the source VM within the source IP subnet(i.e.,VN) is also not visible to the destination routers in the destination VN
beyond the source VN.

Also it seems you don’t consider the outbound traffic for the case when VM is moved from VN1 to VN2 and each VN have only one first hop network device (could be a router)
In such case, the traffic can be forwarded/tunnelled by first hop network device in VN1 to first hop network device in VN2, doesn’t it? Why this case is excluded?
Also in this case, how the destination VM location within destination VN is visible to the source first hop network device in VN1 is still a problem, Doesn’t it?

For other minors issues, like
1.terminology network endpoint, end system, endpoint, it is better to use consistent terminology.
2. I don’t understand the sentence
“
A virtual network may have two routers for
traffic to/from other VNs or external to all VNs
”
What do you mean by virtual network have routers for traffic to external to all VNs.
3. Is router a right term? It seems in other place you use first hop network device, it doesn’t exclude switch to be used.
I can come up a specific text proposal if you allow for couples of days. Thanks for taking my comment into account.

Regards!
-Qin
发件人: [email-masked] [mailto:[email-masked]] 代表 Eric Gray
发送时间: 2013年3月14日 23:21
收件人: [email-masked]
主题: [nvo3] Comments on draft-ietf-nvo3-overlay-problem-statement

Had to forward this as the commenter used an invalid email address.

Sent from my iPad

Begin forwarded message:
From: Mail Delivery Subsystem <[email-masked]<mailto:[email-masked]>>
Date: March 13, 2013, 5:11:01 PM EDT
To: [email-masked]<mailto:[email-masked]>
Subject: Delivery Status Notification (Failure)
Delivery to the following recipient failed permanently:

    [email-masked]<mailto:[email-masked]>

Technical details of permanent failure:
DNS Error: Domain name not found

----- Original message -----

Subject: Your comment on draft-ietf-nvo3-overlay-problem-statement-02
From: Eric Gray <[email-masked]<mailto:[email-masked]>>
Date: Wed, 13 Mar 2013 17:10:59 -0400
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Qin,

In reading your comment, it seems that you're both asking what we
mean by the text and answering the question with your next question.

The text you ask about is identifying the case where more than one
router connects a virtual network to an otherwise separate virtual
network.  The optimal forwarding concern is that it is difficult for a
virtual host or server located within the first virtual network to know
which of the multiple routers connecting the two virtual networks is
the optimal choice for connecting to a host or server in the second
virtual network.

This is a concern when there are possibly multiple local forwarding
devices between the first host/server and any of the potential routers
that connect the two virtual networks and/or a similar situation exists
in the second virtual network between any of these candidate routers
and the second host/server.  How is the host supposed to determine
which of the multiple routers in this case provides the optimal path.

This is pretty much the case you identify when you ask how we are
"going to deal with the optimal forwarding between two VMs [that]
belong to different subnet[s]."

It seems that we're at least talking about the same thing.  Can you
make a specific text proposal that would make our text clearer?

--
Eric

You wrote:
I reviewed the change in section 3.7 "optimal forwarding"of NVO3 problem statement.
It said:
"
  IP implementations in network endpoints typically do not distinguish
  between multiple routers on the same subnet - there may only be a
  single default gateway in use, and any use of multiple routers
  usually considers all of them to be one-hop away.
"
It seems you talk about one tenant system is multihomed to multiple NVEs in the same subnet.
I am not sure how much of this is related to optimal forwarding?
Are you assuming only one NVE is active? or all the NVEs placed in the same subnet are active?
or some of NVE placed in the same subnet are active to a set of VMs while the other

---

From: Qin Wu <[email-masked]>
Date: Thu, 11 Apr 2013 09:45:05 +0000

Hi, Eric:
Here is my proposed change to section 3.7 of draft-ietf-nvo3-overlay-problem-statement:
OLD TEXT:
“
3.7.  Optimal Forwarding

   Another problem area relates to the routing of traffic into and out
   of a virtual network.  A virtual network may have two routers for
   traffic to/from other VNs or external to all VNs, and the optimal
   choice of router may depend on where the VM is located.  The two
   routers may not be equally "close" to a given VM.  The issue appears
   both when a VM is initially instantiated on a virtual network or when
   a VM migrates or is moved to a different location.  After a
   migration, the VM's closest router for such traffic may change, i.e.,
   the VM may get better service by switching to the "closer" router,
   and this may improve the utilization of network resources.

   usually considers all of them to be one-hop away.  Routing protocol
   functionality is constrained by the requirement to cope with these
   endpoint limitations - for example VRRP has one router serve as the
   master to handle all outbound traffic.  This problem can be
   particularly acute when the virtual network spans multiple data
   centers, as a VM is likely to receive significantly better service
   when forwarding external traffic through a local router by comparison
   to using a router at a remote data center.

   The issue is further complicated when middleboxes (e.g., load-
   balancers, firewalls, etc.) must be traversed.  Middle boxes may have
   session state that must be preserved for ongoing communication, and
   traffic must continue to flow through the middle box, regardless of
   which router is "closest".
”
NEW TEXT:
“
3.7.  Optimal Forwarding

   Another problem area relates to the routing of traffic into and out
   of a virtual network. A virtual network may at least have one edge
device (e.g., router) for forwarding traffic to/from other VNs or
non-virtualized networks external to all VNs.  The issue appears both
when a VM is initially instantiated on a virtual network and migrates
or is moved to a different place. After a migration, the VM's closest
edge device for such traffic may change (e.g.,moved to a different VN
using a edge device different from one before it is moved). The VM may
get better service by switching to the "new" edge device.

This issue is complicated when a virtual network have more than one
edge device (e.g., router) for forwarding traffic to/from other VNs
or non-virtualized networks external to all VNs, and the optimal
   choice of edge device may depend on where the VM is located.  The two
   edge devices may not be equally "close" to a given VM.  The VM may get
better service by switching to the "close" edge device,and this may
improve tenant’s user experience and the utilization of network resources.

   IP implementations in network endpoints typically do not distinguish
   between multiple edge devices on the same subnet - there may only be a
   single default gateway in use, and any use of multiple routers and
   all of them are usually considered to be one-hop away.  Routing protocol
   functionality is constrained by the requirement to cope with these
   endpoint limitations - for example VRRP has one router serve as the
   master to handle all outbound traffic.  This problem can be
   particularly acute when the virtual network spans multiple data
   centers, as a VM is likely to receive significantly better service
   when forwarding external traffic through a local router by comparison
   to using a router at a remote data center.

   The optimal forwarding problem applies to both outbound and inbound
traffic.  For outbound traffic, when a virtual network have more than one
egress edge device (e.g., egress router), the choice of outbound edge device
   determines the path of outgoing traffic from the VM, which may be
   sub-optimal after a VM move.  For inbound traffic, the location of
   the VM within the IP subnet for the VM is not visible to the edge device
   beyond the virtual network.  Thus, the routing infrastructure will
   have no information as to which of the two externally visible
   gateways leading into the virtual network would be the better choice
   for reaching a particular VM.

   The issue is further complicated when middleboxes (e.g., load-
   balancers, firewalls, etc.) must be traversed.  Middle boxes may have
   session state that must be preserved for ongoing communication, and
   traffic must continue to flow through the middle box, regardless of
   which router is "closest".

”

Regards!
-Qin
发件人: Qin Wu
发送时间: 2013年4月9日 16:02
收件人: 'Eric Gray'; [email-masked]
主题: 答复: [nvo3] Comments on draft-ietf-nvo3-overlay-problem-statement

Hi, Eric:

Regards!
-Qin

Sent from my iPad

Begin forwarded message:

----- Original message -----

Qin,

--
Eric

You wrote:

---

From: Thomas Narten <[email-masked]>
Date: Wed, 17 Apr 2013 12:38:08 -0400

Hi Qin.

Thanks for the suggested text. It helps clarify the concerns you
have. From your proposal, you seem to be raising the following: 

1) We use the term "router" to refer to the device that relays traffic
between devices connected to two different VNs, as well as for
relaying traffic between devices A and B, where A is attached to a VN,
while B is a conventional device not connected to a VN at all (e.g.,
it could be out on the Internet or on the DCN).

You use the term "edge device" for this, but I think that is even less
clear. I used the term "router" because it is acting much like a
traditional router. It supports IP, and it it relays traffic between
devices connected to different IP subnets.

Maybe the term "gateway" would be better?

2) you've added some text, but I'm having difficulty seeing what it is
trying to clarify.

That said, how about I reword the first paragraph to say:

OLD:

    Another problem area relates to the routing of traffic into and
    out of a virtual network.  A virtual network may have two routers
    for traffic to/from other VNs or external to all VNs, and the
    optimal choice of router may depend on where the VM is
    located. The two routers may not be equally "close" to a given
    VM. The issue appears both when a VM is initially instantiated on
    a virtual network or when a VM migrates or is moved to a different
    location. After a migration, the VM's closest router for such
    traffic may change, i.e., the VM may get better service by
    switching to the "closer" router, and this may improve the
    utilization of network resources.

New:

    Another problem area relates to the optimal forwarding of traffic
    between peers that are not connected to the same virtual network.
    Such forwarding happens when a host on a virtual network
    communicates with a host not on any virtual network (e.g., an
    Internet host) as well as when a host on a virtual network
    communicates with a host on a different virtual network.  A
    virtual network may have two (or more) gateways for forwarding
    traffic onto and off of the virtual network and the optimal choice
    of which gateway to use may depend on the the set of available
    paths between the communicating peers. The set of available
    gateways may not be equally "close" to a given destination. The
    issue appears both when a VM is initially instantiated on a
    virtual network or when a VM migrates or is moved to a different
    location. After a migration, for instance, a VM's best-choice
    gateway for such traffic may change, i.e., the VM may get better
    service by switching to the "closer" gateway, and this may improve
    the utilization of network resources.

Does that help?

Thomas

---

From: Qin Wu <[email-masked]>
Date: Thu, 18 Apr 2013 01:51:56 +0000

Hi, Thomas:
Your proposed text improve a lot since it deal with both communication 
between two VN but also communication between one VN and one 
Non-VN, using general term "gateway" makes sense to me.
Regarding my added text, what I am trying to say if we need to 
consider VM movement between two VNs (i.e.,VM mobility case), 
suppose, one VM is moved from VN1 to VN2, each VN has a gateway 
for forwarding traffic (Gateway1 for VN1, Gateway2 for VN2), When VM1
is moved to VN2 and is still communicating with VM3 in VN1, the Gateway1 
which the VM1 is previously anchored to(VM3 is also anchored to Gateway1)
is obviously changed to Gateway2. This is the case I claimed to be basic or 
simple case. In this case, we don't have more than one gateway in each VN
for forwarding traffic, how do we deal with this use case? 
Shall we ignore it? Or Solution is obvious and it is not worth dealing with this case? It is not clear to me.

Regards!
-Qin
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Thomas Narten
发送时间: 2013年4月18日 0:38
收件人: Qin Wu
抄送: Eric Gray; [email-masked]
主题: Re: [nvo3] 答复: Comments on draft-ietf-nvo3-overlay-problem-statement

Hi Qin.

OLD:

New:

Does that help?

Thomas

_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Jon Hudson <[email-masked]>
Date: Thu, 18 Apr 2013 03:03:29 +0100

Looks good, and I agree that Gateway is more clear.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 18 Apr 2013 08:41:05 -0400

Hi Qin.

> consider VM movement between two VNs (i.e.,VM mobility case),

IMO, no.

My assumption is that the basic model we have is that a VM is
associated with one VN (** but see below). Movement from one VN to
another is not really part of the model. Movement from one VN to
another raises a bunch of questions, including, perhaps whether a
change in IP address of the VM is needed.

Unless someone can make a compelling argument for this case (i.e.,
what the use case and semantics are), I just see it as adding
complexity without value.

**note: a VM can be associated with more than one VM, but then it has
multiple interfaces, each connected to one VN. But then, movemment
from one VN to another implies that one interface is first associated
with VNA and then with VNB, which then falls back to the same case
as a VM having only one interface and one VN connection. 

Thomas

---

From: "Black, David" <[email-masked]>
Date: Thu, 18 Apr 2013 10:11:26 -0400

+1, --David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas
> Narten
> Sent: Thursday, April 18, 2013 8:41 AM
> To: Qin Wu
> Cc: Eric Gray; [email-masked]
> Subject: Re: [nvo3] 答复: 答复: Comments on draft-ietf-nvo3-overlay-problem-
> statement
> 
> Hi Qin.
>

---

From: Paul Unbehagen <[email-masked]>
Date: Thu, 18 Apr 2013 10:12:30 -0600

+1

--
Paul Unbehagen

---

From: "Reith, Lothar" <[email-masked]>
Date: Thu, 18 Apr 2013 20:24:50 +0000

+1 Lothar

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Thu, 18 Apr 2013 21:47:26 +0000

+1 - Larry

---

From: Qin Wu <[email-masked]>
Date: Sat, 20 Apr 2013 02:57:02 +0000

Hi, Thomas:
Thank for your clarification to this VM mobility issue.
I thought that is the issue we can potentially talked about although we have no idea
Whether this issue is workable. But I agree this issue may add a lot of complexity to the 
network when we think to introduce some new functionalities to tackle it.

I am okay to take it out unless we have more concrete proposal to fix this.
Thanks for taking my comments into account. I would like to see your update to incorporate
The improving text you proposed in this thread. 

Regards!
-Qin
-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Thursday, April 18, 2013 8:41 PM
To: Qin Wu
Cc: Eric Gray; [email-masked]
Subject: Re: [nvo3] 答复: 答复: Comments on draft-ietf-nvo3-overlay-problem-statement

Hi Qin.

IMO, no.

Thomas