Re: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 / section 4.2.2

Thomas,

What about the following:

> 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.

BTW, I don’t think there is anything fundamentally wrong with "control plane learning" expression. In fact, it is used all over the place in many ietf documents I am familiar with.

Maria

> -----Original Message-----
> From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of
> thomas.morin@orange.com
> Sent: Tuesday, July 03, 2012 7:51 AM
> To: nvo3@ietf.org
> 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:marc.lasserre@alcatel-lucent.com] Sent: Monday, July 02,
>  >> 2012 12:29 PM To: NAPIERALA, MARIA H; Luyuan Fang (lufang); Pedro
>  >> Roque Marques; <david.black@emc.com> Cc: nvo3@ietf.org 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: nvo3-bounces@ietf.org
>  >>> [mailto:nvo3-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA H
>  >>> Sent: Monday, July 02, 2012 6:13 PM To: Luyuan Fang (lufang);
>  >>> LASSERRE, MARC (MARC); Pedro Roque Marques;
>  >>> <david.black@emc.com> Cc: nvo3@ietf.org 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:lufang@cisco.com] Sent: Monday, July 02, 2012 11:58 AM
>  >>>> To: LASSERRE, MARC (MARC); NAPIERALA, MARIA H; Pedro Roque
>  >>>> Marques; <david.black@emc.com> Cc: nvo3@ietf.org 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: nvo3-bounces@ietf.org
>  >>> [mailto:nvo3-bounces@ietf.org] On Behalf
>  >>>> Of
>  >>>>> LASSERRE, MARC (MARC) Sent: Monday, July 02, 2012 9:04 AM To:
>  >>>>> NAPIERALA, MARIA H; Pedro Roque Marques;
>  >> <david.black@emc.com>
>  >>>>> Cc: nvo3@ietf.org 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: nvo3-bounces@ietf.org
>  >>>>>> [mailto:nvo3-bounces@ietf.org] On Behalf Of NAPIERALA,
>  >>>>>> MARIA H Sent: Saturday, June 30, 2012 2:18 AM To: Pedro
>  >>>>>> Roque Marques; <david.black@emc.com> Cc: nvo3@ietf.org
>  >>>>>> 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:
>  >>>>>>>>> nvo3-bounces@ietf.org
>  >>> [mailto:nvo3-bounces@ietf.org] On
>  >>>>>>>>> Behalf
>  >>>>>>> Of
>  >>>>>>>>> NAPIERALA, MARIA H Sent: Friday, June 29, 2012 2:14
>  >>>>>>>>> PM To: nvo3@ietf.org 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
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3