Marc, Please see inline.
> > > Can you point to a specific paragraph where it is mentioned > > or implied > > > that a tenant network can only consist of a single VN? > > [Lucy] Figure 3 is the generic reference model and figure 4 > > is the model for NVE. Do you think these two reference models > > can represent the network virtual overlay for the tenant > > systems in the same and different VNs? If yes, please > > explain. I only see the former. > > While these are generic pictures, figure 4 does show that tenant > systems are attached via VAPs to specific VNIs. A set of VNIs with the > same VN context (eg VNID) represents a VN. A Tenant system with > multiple interfaces can attach to different VNIs, hence be part of > different VNs. All this would be quite hard to represent in a single > figure. Some add'l text might be needed for clarity. > [Lucy] This is not my point. But agree that a tenant system may participate more than one VN. My point is more about how two VNs interconnect each other. Are you saying that this is the way that two VN interconnecting each other, i.e. via a VM? > > > > > > > > > > > > 2) Figure 2 illustrate a logical service connectivity for > > a single > > > > tenant. First of all, it should not show L3 infrastructure in the > > > > figure at all. Second, I interpret this > > > > > > How can routing be avoided when VMs attached to different > > L2 networks > > > have to communicate? > > [Lucy] This is not my point. My point is: this is the tenant > > network logical topology view. Why does it show underlying L3 > > infrastructure between Rtr1 and Rtr2? Tenant has one Routing > > domain and three L2 domain. That is what figure should show, right? > > VMs do not care what is behind the router boundary. But a tenant knows > that routers run over an L3 infrastructure even if in its simplest form > both rtr1 and rtr2 could be directly connected. Hence, this is logical > connectvity as seen by a tenant. [Lucy] IMO, a tenant topology view should only include the domains, i.e. sub network. If that Rtr1 and Rtr2 represent two different administration domains, then we talk about nvo federation. Anyway, I still don't see why L3 infrastructure should be shown in this figure. Regards, Lucy > > > > > > > > figure as one tenant network consisting of four virtual networks, > > > > three L2 virtual networks and one L3 virtual network. It should > > > > point out that VMs on a L2 virtual network may reside on > > the same or > > > > different servers. The drawing and team LAN make easy to > > thing they > > > > are physical LANs. In fact they are not. VM on LAN11 and > > VM on LAN12 > > > > may reside on the same server. Thus it is very important to state > > > > them out clearly. Finally, based on my comment 1), it > > should clarify > > > > what this document address regarding to this figure here. > > > > > > This is a *logical* and not a physical connectivity view. > > > Whether VMs are on the same server or not is irrelevant. > > > Traffic between VMs in the same L2 network is still switched (by a > > > virtual or physical switch). > > > > > [Lucy] OK, this is what I picture. Furthermore, the "logical" > > also indicate that VM in LAN11 communicate with VM in LAN12 > > MUST go through L3 overlay. > > > > > > > > > > > 3) in Section 3.3, "In DC environments utilizing VM > > technologies, an > > > > important feature > > > > is that VMs can move from one server to another > > server in the > > > > same > > > > or different L2 physical domains (within or across > > DCs) in a > > > > seamless manner." > > > > > > > > What does the L2 physical domain mean here? Why need to > > mention this? > > > > > > > > > > I'm fine with changing the sentence to "In DC environments > > utilizing > > > VM technologies, an important feature is that VMs can move from one > > > server to another server (within or across DCs) in a > > seamless manner". > > [Lucy] that is good. > > > > Regards, > > Lucy > > > > > > > > > > > Cheers, > > > > Lucy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: [email protected] [mailto:[email protected]] > > > > On Behalf > > > > > Of Benson Schliesser > > > > > Sent: Friday, February 22, 2013 6:28 PM > > > > > To: [email protected] > > > > > Subject: [nvo3] WG Last Call for draft-ietf-nvo3-framework-02 > > > > > > > > > > This email begins a two week working group last call for > > > > > draft-ietf-nvo3-framework-02. > > > > > > > > > > Please review the draft and post any comments to the NVO3 list. > > > > > > > > > > This working group last call will end on Friday 08-March-2013. > > > > > > > > > > Cheers, > > > > > -Benson & Matthew > > > > > _______________________________________________ > > > > > nvo3 mailing list > > > > > [email protected] > > > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > > > > nvo3 mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
