Janos, I have used these terms in our email exchange but I did not plan to use them in the draft. Thanks for pointing out the misleading text in the original introduction.
I will address your add'l comments in a separate mail. Marc > -----Original Message----- > From: János Farkas [mailto:[email protected]] > Sent: Saturday, June 30, 2012 9:36 AM > To: LASSERRE, MARC (MARC) > Cc: [email protected] > Subject: Re: [nvo3] call for adoption: > draft-lasserre-nvo3-framework-02 > > Hi Marc, > > > The limitations stated are still valid in most > Ethernet-based (albeit > traditional) DCs. > > I'm afraid the word "traditional" (and phrases alike) is not > well defined, specific and exact. I would avoid using it in a > standard specification. > > > Understood but these technologies are not that common in > data centers yet, even if available from some vendors. > > I'm afraid I also fail to translate this sentence to be > applicable in a standard. > > As far as I understand these type of statements are not > exact. Does not seem to mean much more than DCs built upon > 20th century technology may have some issues, and one has to > do something if aims to get rid of these issues. In order to > achieve that, an upgrade is needed for such DCs, e.g. to the > NVO3 solution, which may be not that common in data centers > yet, even if it is available from some vendors. > > Please do not misunderstand me. All I'm trying to point on in > my comments is to have exact, specific and correct statements > in a standard as much as possible. I'm not arguing for any > specific solution. This is a framework document; I think it > should be quite generic and solution independent, and in-line > with the specification of the charter. > > Regards, > Janos > > > > On 6/29/2012 6:35 PM, LASSERRE, MARC (MARC) wrote: > > Hi Janos, > > > > See my comments below. > > > > Thanks, > > Marc > >> -----Original Message----- > >> From: János Farkas [mailto:[email protected]] > >> Sent: Friday, June 29, 2012 5:42 PM > >> To: LASSERRE, MARC (MARC) > >> Cc: [email protected] > >> Subject: Re: [nvo3] call for adoption: > >> draft-lasserre-nvo3-framework-02 > >> > >> Marc, > >> > >> On 6/29/2012 5:17 PM, LASSERRE, MARC (MARC) wrote: > >>> Janos, > >>> > >>> It is well understood that PBB and SPBM address traditional > >> Ethernet limitations. > >> > >> PBB and SPB are approved and deployed standards. This is Ethernet > >> today. > > Understood but these technologies are not that common in > data centers yet, even if available from some vendors. > > > > > >> With respect to Ethernet, all I suggest is to remove statements on > >> Ethernet limitations that are not valid today. > > The limitations stated are still valid in most > Ethernet-based (albeit traditional) DCs. > > > >>> However, our intent is not to focus the nvo3 framework > >> towards specific L2 technologies. > >>> In fact, nvo3 targets IP and/or MPLS as the underlying > >> transport and not Ethernet-based transport. > >> > >> As I wrote below: > >> "I understand that the WG aims to provide a solution over L3. > >> Nevertheless, it seems to me that it would be better to give other > >> motivation for it than L2 has issues, given that no issue has been > >> pointed out that is still valid for Ethernet today." > >> > >> I'm not against any L3 solution and clearly understand > that the goal > >> here is to provide one. I guess it has other motivation than L2 is > >> poor. > > True, it is also motivated by the fact that some DC > operators prefer an IP-based solution. > > I could make this clearer in the draft. > > > > > >> All I pointed out in my comments to the introduction is > that I think > >> it would be better to explain that motivation in the introduction. > >> Note further, that my comments to the document are not more > >> L2 specific than the text itself in the draft. > >> > >> Best regards, > >> Janos > >> > >> > >>> 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. > >>>> > >>>> > >>>> 1. Introduction > >>>> > >>>> "Limited VLAN space" > >>>> The 12-bit overlay network ID limitation of the Ethernet > header is > >>>> not there any more for several years. There are > different types of > >>>> VLANs. > >>>> The I-SID can be considered as a 24-bit VLAN ID, which is > >> sometimes > >>>> called I-VLAN. Furthermore, there exist B-VLANs and > >> S-VLANs aside the > >>>> C-VLANs that were defined at the first place. The combination of > >>>> these VLANs provides flexibility for network virtualization; > >>>> altogether the Ethernet header today provides 60 bits > for network > >>>> virtualization. > >>>> It would be better to remove this because the limitation > >> is not there > >>>> today. > >>>> > >>>> "FIB explosion due to handling of large number of MACs/IP > >> addresses" > >>>> FIB explosion might be there in a L2 network if the > >> already available > >>>> L2 network virtualization tools are not used. FIB > explosion is not > >>>> likely in a PBB network. > >>>> It would be better to update the bullet accordingly or remove it. > >>>> > >>>> "Spanning Tree limitations" > >>>> L2 networks are not limited to a single spanning tree > for several > >>>> years. > >>>> Shortest Path Bridging (SPB) provides shortest path > forwarding and > >>>> uses physical links that might have been blocked by a > >> single spanning > >>>> tree instance. Moreover, MSTP also provides multiple > spanning tree > >>>> instances, which allow the use of the physical links. > >>>> It would be better to remove the bullet. > >>>> > >>>> "Broadcast storms" > >>>> Broadcast storms are not necessarily there in today's L2 > networks, > >>>> e.g. > >>>> there are no broadcast storms at all in an SPBM network. > >> Furthermore, > >>>> applying the existing L2 network virtualization techniques, the > >>>> broadcast due to unknown destination is kept within the virtual > >>>> network, thus it is not a broadcast storm. > >>>> It would be better to update the bullet such that it exactly > >>>> specifies the problem or remove it. > >>>> > >>>> "Inefficient Broadcast/Multicast handling" > >>>> It is not clear what is meant here, it would be better > to be more > >>>> specific. (If it is about L2, then the statement is not valid. > >>>> Handling of multicast is very efficient in L2, both > shortest path > >>>> trees and shared threes can be used today.) > >>>> > >>>> "Limited mobility/portability support" > >>>> It is not clear what is meant here. Is it about VM > >> migration? If so, > >>>> then the statement is not exact for L2, VDP supports VM > migration. > >>>> (Furthermore, L2 networks typically automatically learn the new > >>>> location of a station after its movement.) > >>>> > >>>> "Lack of service auto-discovery" > >>>> If it is about L2, then that is not the case. SPB has in-built > >>>> service auto-discovery. > >>>> It would be better to be more specific in the bullet or > remove it. > >>>> > >>>> The issue list is introduced as "Existing virtual network > >> models used > >>>> for data center networks have known limitations, > >> specifically in the > >>>> context of multiple tenants. These issues can be summarized as" > >>>> As the comments to the bullets show the list is not > accurate given > >>>> the existing virtual network models available for data > >> centers today. > >>>> Therefore, it would be better to bring this issue list up > >> to date to > >>>> today's networking technologies. > >>>> (I understand that the WG aims to provide a solution over L3. > >>>> Nevertheless, it seems to me that it would be better to > give other > >>>> motivation for it than L2 has issues, given that no > issue has been > >>>> pointed out that is still valid for Ethernet today.) > >>>> > >>>> > >>>> 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. > >>>> > >>>> "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" > >>>> > >>>> > >>>> 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. > >>>> > >>>> "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. > >>>> > >>>> "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. > >>>> > >>>> > >>>> 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. > >>>> > >>>> > >>>> 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
