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

[David Allan I <[e-mail]>]

Hi Thomas:

It is a definite improvement.

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

Cheers
Dave

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