Hi Dave, 2012-07-03, David Allan I: > > It is a definite improvement.
Good. > Given that one of the reason for a change in the set of addresses is > mobility, coordinating change as described does not sound like it > goes far enough. What we really want is a registration system with > minimal overhead, minimal latency, hence minimal possibilty of race > conditions. > > Without making a meal of it, perhaps... > > "In both cases, coordination with the NVE control protocol is needed > such that when the NVE determines that the set of address(es) behind > a VAP has changed, it triggers the local NVE control plane to > promptly synchronize this information to its peers." Let's not forget this is a framework document, and avoid going into what starts to be requirements on the NVE control plane protocol. Thanks, -Thomas > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Tuesday, July 03, 2012 4:51 AM > To: [email protected] > Subject: Re: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 / > section 4.2.2 > > Hello Maria, Dave, all, > > Here is a proposed rewrite of section 4.2.2 aiming at avoiding the "learning" > term for L3 and take into account the fact that, even for L2, dataplane > learning is just one option among many. > > ---- > 4.2.2 Determining addresses behind VAPs > > For an L2 NVE, the NVE needs to be able to determine MAC > address(es) of the end-systems present on a VAP (for instance, > dataplane-learning may be relied upon for this purpose). For an L3 NVE, the > NVE needs to be able to determine IP address(es) of the end-systems present > on a VAP. > > In both cases, coordination with the NVE control protocol is needed > such that when the NVE determines that the set of address(es) behind a VAP > has changed, it triggers the local NVE control plane to distribute this > information to its peers. > ---- > > Comments ? > > -Thomas > > > > Current text is : > > 4.2.2. Coordination between data plane and control plane > > Often a combination of data plane and control based learning is > necessary. Learning is applied towards end-user facing ports whereas > distribution is used on the tunnel ports. Coordination between the learning > engine and the control protocol is needed such that when a new address gets > learned or an old address is removed, it triggers the local control plane to > distribute this information to its peers. > > > NAPIERALA, MARIA H a écrit : >> Marc, > > > > Regarding the first paragraph, what about saying the following: > > > > "Data plane learning is applicable _only_ to L2 whereas control plane > > learning is applicable to both L2 and L3." > > > > I would remove the second sentence "Control plane learning does not > > require dynamic data plane learning" because it's a tautology. > > > > Also, it is still not clear whether you are assuming that a layer 2 > > solution can be solely based on control plane updates. > > > > Maria > > > > > >> -----Original Message----- From: LASSERRE, MARC (MARC) >> > [mailto:[email protected]] Sent: Monday, July 02, >> 2012 > 12:29 PM To: NAPIERALA, MARIA H; Luyuan Fang (lufang); Pedro >> Roque > Marques; <[email protected]> Cc: [email protected] Subject: RE: > >> [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 >> >> > Maria, all, >> >> I suggest adding the first sentence in section 4.2.1 (see > below) >> for clarification. > >> > >> 4.2.1. Data plane vs Control plane driven >> >> Data plane learning is > applicable to L2 whereas control plane >> learning is applicable to both L2 > and L3. Control plane learning >> does not require dynamic data plane > learning. > >> > >> Data plane learning implies that flooding of unknown destinations >> be > supported and hence implies that broadcast and/or multicast be >> supported. > Multicasting in the core network for dynamic learning >> may lead to > significant scalability limitations. Specific >> forwarding rules must be > enforced to prevent loops from happening. > >> This can be achieved using a spanning tree, a shortest path tree, >> or > a split-horizon mesh. > >> > >> It should be noted that the amount of state to be distributed is a >> > function of the number of virtual machines. Different forms of >> caching > can also be utilized to minimize state distribution between >> the various > elements. > >> > >> -Marc > >> > >>> -----Original Message----- From: [email protected] >>> > [mailto:[email protected]] On Behalf Of NAPIERALA, MARIA H >>> Sent: > Monday, July 02, 2012 6:13 PM To: Luyuan Fang (lufang); >>> LASSERRE, MARC > (MARC); Pedro Roque Marques; >>> <[email protected]> Cc: [email protected] > Subject: Re: [nvo3] call >>> for adoption: draft-lasserre-nvo3-framework-02 > >>> >>> Marc, >>> >>> Yes, this sentence is much more general and not > excluding >>> control-plane only solutions. You might clarify it more by > >>> stating that control plane only solutions with no data plane >>> > learning are also possible (as Luyuan suggested). > >>> > >>> Maria > >>> > >>> > >>>> -----Original Message----- From: Luyuan Fang (lufang) >>>> > [mailto:[email protected]] Sent: Monday, July 02, 2012 11:58 AM >>>> To: > LASSERRE, MARC (MARC); NAPIERALA, MARIA H; Pedro Roque >>>> Marques; > <[email protected]> Cc: [email protected] Subject: RE: > >>>> [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 >>>> >>>> > Marc, >>>> >>>> The sentence is correct, but I think you should clarify > when >>>> data planning learning is applicable, when it is not, e.g. if > >>>> all L3 solutions... Luyuan >>>> >>>>> -----Original Message----- From: > [email protected] >>> [mailto:[email protected]] On Behalf >>>> Of > >>>>> LASSERRE, MARC (MARC) Sent: Monday, July 02, 2012 9:04 AM To: > >>>>> NAPIERALA, MARIA H; Pedro Roque Marques; >> <[email protected]> > >>>>> Cc: [email protected] Subject: Re: [nvo3] call for adoption: > >>>>> draft-lasserre-nvo3-framework- > >>>> 02 > >>>>> > >>>>> Maria, > >>>>> > >>>>> What about the following rewording? > >>>>> > >>>>> "A combination of data plane and control plane based >>> learning > may be >>>>> applicable." > >>>>> > >>>>> Marc > >>>>> > >>>>>> -----Original Message----- From: [email protected] >>>>>> > [mailto:[email protected]] On Behalf Of NAPIERALA, >>>>>> MARIA H Sent: > Saturday, June 30, 2012 2:18 AM To: Pedro >>>>>> Roque Marques; > <[email protected]> Cc: [email protected] >>>>>> Subject: Re: [nvo3] call for > adoption: > >>>>>> draft-lasserre-nvo3-framework-02 >>>>>> >>>>>>>> As has been > pointed out a number of times, pure data >>>>>> plane learning >>>>>>> > leads >>>>>>>> to a lot of BUM traffic flooding, so a combination of >>>>>> > data plane and >>>>>>> control >>>>>>>> plane can work better with existing > systems and >>>>>>>> improve >>>>>> scalability. > >>>>>>> > >>>>>>> Data plane learning, l2 header transparency, bridging >>>>>> > interoperability >>>>>>> are all very reasonable requirements for one type > of >>>>>> data-centers. But >>>>>>> also an unacceptable burden for a > different class of DC >>>>>> designs. In my >>>>>>> view you and Maria are > just looking at different types >>>>>>> of >>>>>> DC designs. > >>>>>>> They are different problems. > >>>>>> > >>>>>> Precisely. And my comment was that the sentence in draft: > >>>>>> "Often a combination of data plane and control based >>> learning > is >>>>>> necessary" seems to be assuming that pretty much all >>> data > centers >>>>>> must use (some) data plane learning. I have suggested >>> to > clarify >>>>>> it. > >>>>>> > >>>>>> Maria > >>>>>> > >>>>>> > >>>>>>> Pedro. > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks, --David > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- From: > >>>>>>>>> [email protected] > >>> [mailto:[email protected]] On > >>>>>>>>> Behalf > >>>>>>> Of > >>>>>>>>> NAPIERALA, MARIA H Sent: Friday, June 29, 2012 2:14 >>>>>>>>> PM > To: [email protected] Subject: Re: [nvo3] call for >>>>>>>>> adoption: > draft-lasserre- >> nvo3- >>>>>>> framework-02 >>>>>>>>> >>>>>>>>> A > comment on section 4.2.2 "Coordination between >>>>>>>>> data >> plane > >>>> and >>>>>>> control plane" > >>>>>>>>> > >>>>>>>>> "Often a combination of data plane and control based >>>>>> > learning is >>>>>>>>> necessary." > >>>>>>>>> > >>>>>>>>> I think this statement is too strong since in a >>>>>>>>> > solution >>>>>> proposed >>>>>>>>> in >>>>>>> draft- >>>>>>>>> > marques-l3vpn-end-system, for example, there is no >>> data plane >>>>>>> > learning in a >>>>>>>>> virtual network. Maybe it should be explain when > >>>>>>>>> such >>>>>> combination >>>>>>>>> is necessary. > >>>>>>>>> > >>>>>>>>> Maria > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> 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/c-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 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
