> >> For an L2 NVE, the NVE needs to be able to determine MAC > >> address(es) of the end-systems present on a VAP (typically > >> dataplane-learning is 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 via a control plane. In the latter case, the data- > plane learning is never involved. > > This last sentence is not incorrect, but on the other hand if someone > tomorrow would like to do consider doing dataplane learning for IP > addresses,
I hope it never happens ;-) is it in the scope of the NVO3 framework document to say he > should not ? > > We can still hint that dataplane learning would be quite unexpected: > > In the latter case, data-plane learning is typically not involved. > I would rather use: "In the latter case, data-plane learning should be not involved. > > > -Thomas > > > > > > > > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On Behalf > Of > >> [email protected] > >> Sent: Tuesday, July 03, 2012 7: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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
