Subject: Re: [nvo3] Updated Charter

From: "T. Sridhar" <[email-masked]>
Date: Wed, 4 Apr 2012 15:09:36 -0700 (PDT)

Stewart,

_____

The more

we can cleanly separate internal and external communication the greater
the chance that we can construct a small set of simple clear work
programmes that will complete in a timely manner.

_____

>> Endorse this. In the same vein, would recommend that Class 1 should be
the immediate one in scope ("need to address in NV03")  while Class 2 is a
"nice to have". 

Thanks,

Sridhar

  _____  

*	From: Stewart Bryant <stbryant at cisco.com
<mailto:[email-masked]> >
*	To: nvo3 at ietf.org <mailto:[email-masked]> 
*	Date: Wed, 04 Apr 2012 11:52:30 +0100
*	In-reply-to: <CAG99temnjujn1JhZw7GPX52HC_vxJgBhWHNHXMhSECm9614YRg
at mail.gmail.com
<mailto:[email-masked]>
*	References: <4FAEEF73-B9C3-4033-BE49-0E1784C6D154 at cisco.com
<mailto:[email-masked]> >
<CAG99temnjujn1JhZw7GPX52HC_vxJgBhWHNHXMhSECm9614YRg at mail.gmail.com
<mailto:[email-masked]>
*	List-id: "L2 \"Network Virtualization Over l3\" overlay discussion
list \(nvo3\)" <nvo3.ietf.org>

  _____  

Dave McDyson asked about three classes of
connectivity:
 
1) a single data center
2) a set of data centers under control of one administrative domain

3) multiple sets of data centers under control of multiple administrative
domains 

Which of these do we *need* to address in NVO3?
 
Once we have decided which of the above we need to address
we can specify the requirements scope appropriately
and if we decide we need to address 2 and or 3 we can
add a deliverable.
 
My concern is that we should only add anything on inter-DC
that impacts the internal DC design. The more
we can cleanly separate internal and external communication
the greater the chance that we can construct a small set
of simple clear work programmes that will complete in
a timely manner.
 
I think that we need to make it clear that how
any external communications requirements
are addressed is outside the scope of the current charter
discussion, and that there should be no expectation
set as to where the work needed to address those
requirements will be undertaken.
 
Stewart

---

From: Santosh Rajagopalan <[email-masked]>
Date: Thu, 5 Apr 2012 16:55:12 -0700

<snip>
> To summarize, what you are saying about all these cases is you want to
> have multiple exit/entry points into a specific overlay, and you want
> NVO3 to help make sure the "closest" exit is used when possible.
> Right?

Yes.
</snip>

I agree that this should be part of the charter. LISP already has 
something similar - it can resolve an address to more than one locator, 
with possibly different weights. You can't do this level of load balancing 
within the L3 network at all, because the outer address is fixed by the 
time it gets there. If you want to spread your traffic across multiple 
exit points, you will need the encapsulator to load-balance among them as 
outer "locator" addresses.

--
Sunny

From:   Shane Amante <[email-masked]>
To:     [email-masked]
Cc:     "Matthew \(Matthew\) Bocci" <[email-masked]>, 
[email-masked], Benson Schliesser <[email-masked]>
Date:   04/05/2012 09:26 AM
Subject:        Re: [nvo3] Updated Charter
Sent by:        [email-masked]

Hi Thomas,

Cutting to the chase, hopefully without losing too much context.

On Apr 5, 2012, at 10:11 AM, Thomas Narten wrote:
[--snip--]
>> True.  However, NVO3 appears headed down a road of needing and,
>> eventually, defining (or, re-using?) a "mapping" function.  If that
>> is the case, then there's room for 'enhancement' above and beyond
>> standard ARP & ICMPv6 RD/ND ...
> 
> The problem I see with this approach is that the mapping is based on
> IP addresses. Given a target IP address, the mapping system presumably
> has no information about the kind of service residing at that address
> and whether or not there are multiple instances of such a service.
> 
> I gather you are suggesting that the mapping system should be
> augmented with such information, so that the mapping function can be
> smarter about what it returns.

Correct.

> Are you willing to scope the problem to the one case of wanting to
> optimize the selection of exit routers?

Yes.

> Or do you see additional
> places where such optimizations would be desireable?

I can't think of any at the moment.

[--snip--]

> To summarize, what you are saying about all these cases is you want to
> have multiple exit/entry points into a specific overlay, and you want
> NVO3 to help make sure the "closest" exit is used when possible.
> Right?

Yes.

Thanks!

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

---

From: Lizhong Jin <[email-masked]>
Date: Fri, 6 Apr 2012 23:37:21 +0800

Hi,
NOV3 is to send the VM/customer traffic through tunnel to the destination.
The traffic placement optimization could be achieved by the tunnel with
different properties. There was tunnel requirements presented during Bof,
but I think the tunnel should not be only determined by destination, but
also path metrics/latency/QoS/resiliency and etc.
So I suggest to change the sentence in the charter:
"the mapping of "inner" (tenant VM) addresses into "outer" (underlying
network) addresses in order to tunnel a packet to the destination VM"
The mapping should be "inner" (tenant VM) addresses into tunnel (or other
similar words), not into "outer" (underlying network) addresses.

Thanks
Lizhong

> --------------------
> From: "LASSERRE, MARC (MARC)" <[email-masked]>
> To: "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Cc:
> Date: Fri, 6 Apr 2012 13:08:47 +0200
> These are certainly issues that we have to discuss and analyze.
>
> On one hand, one must rely on the network to be self-healing but at the
> same time one can rely on optimal placement of workloads based upon
> underlay topological information that gets exchanged with "applications"
> (e.g. orchestration tools).
>
> Specific "cost" metrics (e.g. length of network paths, path usage, path
> latency) can be used for optimized traffic placement.
>
> Hence, we need to study all the possible avenues in order to achieve
> traffic optimality and, as Florin mentioned, decide in which WG(s) to
> tackle this problem.
>
> Marc
>
>