Janos, See my comments below.
Thanks, Marc > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of János Farkas > Sent: Friday, June 29, 2012 3:35 PM > To: [email protected] > Subject: Re: [nvo3] call for adoption: > draft-lasserre-nvo3-framework-02 > > Hi, > > I have some comments to the draft. Please find them below > under the section header they belong to. > Snipped > > 4.1. Pros & Cons > > "Unicast tunneling state management is handled at the edge of the > network. Intermediate transport nodes are unaware of such state. Note > that this is not the case when multicast is enabled in the > core network." > This statement may depend on the solution applied or the > terms used here > might not be entirely clear. Even if the core only provides point to > point tunnels, then those tunnels have to be established in the core, > hence maintenance of some states is required in the core > nodes. If the > core provides multipoint tunnels as well, then of course more > state is > required to maintain a multipoint tunnel in the core than a point to > point tunnel. The type of connectivity that needs to be > provided by the > core depends on the actual location of VMs belonging to the same > group/tenant. If VMs of a group are only behind two NVEs, then it is > enough to provide a point to point connectivity/tunnel by the core > independently of whether the traffic among the VMs is unicast or > multicast. If VMs of a group are behind more than two NVEs, then the > core has to provide a multipoint connectivity between those NVEs; the > way it is provided is solution dependent. This is a generic statement about the fact no tunnel state is mantained in core nodes for unicast tunnels - unlike mutlicast state. > > "Load balancing may not be optimal as the hash algorithm may not work > well due to the limited number of combinations of tunnel source and > destination addresses" > There are other possibilities of load balancing besides hash. > It would be better to update the sentence to "Hash-based load > balancing > may not be optimal as the hash algorithm may not work well due to the > limited number of combinations of tunnel source and > destination addresses" Fine. > > > 4.2.1. Data plane vs Control plane driven > > "Multicasting in the core network for dynamic learning can lead to > significant scalability limitations." > Multicast should be kept within the virtual network even while it is > transmitted in the core, which can be aided by service > auto-discovery. > Having these features, the scalability limitations should not be > significant. How about "may lead to " instead of "can lead to" then? > > "Specific forwarding rules must be enforced to prevent loops from > happening. This can be achieved using a spanning tree protocol or a > shortest path tree, or using a split-horizon mesh." > "a spanning tree protocol" is not the same category as "a > shortest path > tree" or "split horizon mesh" here. The first one is a > protocol, while > the latter two are forwarding rules as said in the beginning of the > sentence. > It would be better to remove "protocol" from the sentence or > resolve it > another way. Fine > > "the amount of state to be distributed is a function of the number of > virtual machines." > This 'function' is not that easy to draw, it depends on a lot of > factors, furthermore it is most likely that the state to be > maintained > does not depend on the way the state is installed, i.e. it is > the same > both for the control and the data plane driven cases. > For example, there is no need to maintain any state if the > connectivity > is point to point through the core, i.e. a group of VMs are > only behind > two NVEs. > We can take a look on mapping tables e.g. by having an > example of three > NVEs: NVE-A, NVE-B and NVE-C providing the connectivity > through the core > for a group of VMs. If VM1 behind NVE-A communicates with VN2 behind > NVE-B, then the mapping table in NVE-A is VN2->NVE-B, i.e. > NVE-A has to > address the packets to NVE-B for the transmission through the core if > any VM behind NVE-A sends them to VN-2. Similarly the mapping > table is > VN1->NVE-A in NVE-B. It does not matter how these mapping tables are > maintained, the same states should be there. That is, states are the > same both for data and control plane driven mapping tables. > If state here means a mapping state, then it would be better > to update > the cited sentence. Moreover, maybe this section is not the best > location for it. One way out is to remove the paragraph. > Alternatively > it can be updated, e.g. "the amount of state to be > distributed depends > on the network scenario, the grouping and the number of > virtual machines." > If the state means something else, then it would be useful to clarify > what exactly meant here. > Fine. I do not have a problem either removing this sentence or updating it to "the amount of state is dependent upon network topology and the number of VMs". > > 4.2.6. Interaction between network overlays and underlays > > Is it really the case that the DC provider wants to give > visibility of > its infrastructure to its Tenants? Isn't it that the Tenant gets is > overlay and the underlay should be completely hidden? For example, if > the Tenant buys L2aaS, does/should it bother with the fact that L2 > overlay happens to be provided by an L3 underlay? Maybe the > direction of > SLAs would be more appropriate here than providing visibility of the > underlay. This is not about providing visibility to tenants. It is about running multiple overlay services over a common underlay. > > > Best regards, > János > > > > On 6/18/2012 11:51 PM, Benson Schliesser wrote: > > Dear NVO3 Participants - > > > > This message begins a two week Call for Adoption of > http://tools.ietf.org/html/draft-lasserre-nvo3-framework-02 > by the NVO3 working group, ending on 02-July-2012. > > > > Please respond to the NVO3 mailing list with any statements > of approval or disapproval, along with any additional > comments that might explain your position. Also, if any NVO3 > participant is aware of IPR associated with this draft, > please inform the mailing list and/or the NVO3 chairs. > > > > Thanks, > > -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
