I agree with both Larry and Benson; these things belong in the gap
analysis. Lets keep the problem statement focused so we can wrap this thing up.
--Tom
> Hi Linda,
>
> I tend to agree with Benson here. I think the potential issues that Linda
> raises can only be said to be issues if you consider a specific solution or
> data center architecture. Depending on the choices made, there may be
> tradeoffs that will expose one or more of the issues raised. Perhaps these
> belong in the Gap Analysis since the GA analyzes solutions.
>
> - Larry
>
> From: Benson Schliesser <[email protected]>
> Date: Friday, March 1, 2013 5:02 PM
> To: Linda Dunbar <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [nvo3] WG Last Call for
> draft-ietf-nvo3-overlay-problem-statement-02
>
> Hi, Linda.
>
> To clarify: I described them as solution based because they might not be
> present in all different solutions.
>
> For example, a number of your issues stem from the gateway's location. But
> some approaches might have distributed gateways. An L3 service in the NVE
> might not experience any of these gateway issues, for example, depending on
> the network design.
>
> Nevertheless, these are definitely things to consider. Thus my suggestion - I
> think it would be helpful if these issues were rephrased as requirements.
>
> Cheers,
> -Benson
>
>
>
> On Mar 1, 2013, at 18:36, Linda Dunbar <[email protected]> wrote:
>
>> Benson,
>>
>> I only point out some Data Center issues not solved by overlay and issues
>> introduced by IP overlay. I think that NV03 as an IETF working group for
>> data centers with large number of mobile virtual machines, the problem
>> statement should have a section describing those points.
>>
>> I really don’t see how those issues are solution based. Can you elaborate
>> why do you see those are solution based?
>>
>> Best regards,
>> Linda
>>
>> From: Benson Schliesser [mailto:[email protected]]
>> Sent: Friday, March 01, 2013 5:30 PM
>> To: Linda Dunbar; [email protected]
>> Subject: Re: [nvo3] WG Last Call for
>> draft-ietf-nvo3-overlay-problem-statement-02
>>
>> Hi, Linda.
>>
>> I think the NVO3 Problem Statement is intended to describe the problems that
>> motivate our work, rather than repercussions of a particular approach.
>> Speaking for myself, I observe that these issues are very much
>> solution-dependent, and I think they are more appropriate inputs for the
>> requirements drafts rather than the PS. As chair, I'd be interested in
>> hearing what the authors and other contributors think about this.
>>
>> Cheers,
>> -Benson
>>
>>
>> On Mar 1, 2013, at 18:10, "Linda Dunbar" <[email protected]> wrote:
>>
>> Thomas, et al,
>>
>> This draft has done a very good job in describing the motivation for overlay
>> and its potential control/data plane.
>>
>> However, the draft hasn’t described the issues introduced by overlay and
>> large DC issues not solved by overlay. For example:
>>
>> - Multicast issues introduced by overlay:
>> o IP Encapsulation by NVE (or virtual switches on server) means that any
>> layer 2 multicast from or to VMs requires Layer 3 Multicast/broadcast
>> support in the core.
>> o Majority of virtual switches in server won’t have attached VMs
>> participating in any Multicast groups. Therefore, it may not be cost
>> effective for them to support Layer 3 multicast protocol, e.g. PIM, etc.
>> o For virtual switches that do have attached VMs participating in
>> multicast, there are much more dynamic states due to VM moves.
>> o The head end replication will require hypervisor virtual switches to
>> keep up multicast member states, which can change frequently. Therefore,
>> those NVEs, if required to support multicast, have to do more than MPLS
>> (MVPN) multicast supported by PE routers.
>> o
>> - Bottleneck at gateway nodes:
>> o The draft has emphasized greatly on the importance of tenant separation.
>> That means two VMs under the same NVE, if they belong to two different
>> virtual network instances, the communication between them have to go all the
>> way to their default gateway.
>> o Some end stations even have specific default gateway configured. That
>> require all the inter VNI communication to go through their designated
>> gateway nodes.
>> o Many data centers have their FW/LB co- located with GW nodes. That means
>> all the inter VNI communications have to hairpined to those GW nodes.
>>
>> - issues that are not solved by overlay:
>> o The draft is for environment where VMs can move anywhere, which require
>> the Gateway nodes to be aware of individual VM addresses and their
>> corresponding egress NVEs.
>> o Many large Data Centers have small number of gateway nodes interfacing
>> with external network, e.g. 2/4/8/more. Very often, those external facing
>> gateway nodes are the entrance and exit points for all virtual network
>> instances.
>> o Very often each of them can receive traffic for all virtual network
>> instances hosted in the data center.
>> o That means they all need to be aware of individual VMs and their
>> corresponding egress NVEs in the data center. i.e. they may all need host
>> routing. It is true that many routers can handle millions of routes, but the
>> question is if it is necessary for data center gateway nodes to be those
>> high capacity routers.
>> -
>> Therefore, I think that the NV03 problem statement draft should add a new
>> section to describes issues introduced by overlay and issues not solved by
>> overlay.
>>
>> Linda Dunbar
> _______________________________________________
> nvo3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
