Hi David,

 

Thanks for your comment, but you obviously have not understood the
problem I tried to explain.

I totally agree with Marc that data plane learning has to be integrated
with encapsulation and decapsulation to make

data plane learning work over an NVO3 encapsulation. That is not the
problem. The problem I see is that according

to section 3.2.1 "L2 VNI" the L2 VNI shall learn the association of a
source MAC address to an L3 tunnel destination

address, although this entity is not involved in any of the
encapsulation/decapsulation functions. These tunneling

functions are performed by the Overlay Module, so the Overlay Module has
to learn these mappings and not the L2 VNI.

 

Thanks,

Florian


>>> "Black, David" <[email protected]> 12.02.13 18.21 Uhr >>>







> I do not really understand how the source MAC address of a frame
received from an overlay

> tunnel can be learned against the L3 tunnel destination address by an
L2 NVI, since the

> Overlay module already removed the overlay encapsulation header before
the frame is

> delivered to the L2 VNI.

 

There’s a lot of running code that does this in practice (e.g., this is
how VXLAN works today), and I concur w/Marc’s note that effectively says
that dataplane learning has to be integrated with encapsulation and
decapsulation to make dataplane learning work over an nvo3
encapsulation.

 



Thanks,
--David



 




From: [email protected] [mailto:[email protected]] On Behalf Of
LASSERRE, MARC (MARC)
Sent: Tuesday, February 12, 2013 8:13 AM
To: Florian Mahr; [email protected]
Subject: Re: [nvo3] Questions on
draft-ietf-nvo3-dataplane-requirements-00



 

Hi Florian,

 

As a general statement, being a requirements document, some
implementation details have not been specified. This is left to specific
solutions drafts to address.

 

In particular, it does not describe which information specific *logical*
modules have access to.

 

There are several possible ways of exchanging information between such
logical modules. One way, as you have mentioned, is for the overlay
module to  access VNIs. Another way would be via the exchange of
specific context information.

 

The next revision could clarify these points if necessary.

 

Thanks,

Marc

 


 







From: [email protected] [mailto:[email protected]] On Behalf Of
Florian Mahr
Sent: Tuesday, February 12, 2013 1:39 PM
To: [email protected]
Subject: [nvo3] Questions on draft-ietf-nvo3-dataplane-requirements-00


I have some questions on the current NVO3 Data Plane Requirements draft
[draft-ietf-nvo3-dataplane-requirements-00].



 



In section 3.2.1 L2 VNI it states:
"Forwarding table entries provide mapping information between MAC
addresses and L3 tunnel destination addresses. Such entries MAY be
populated by a control or management plane, or via data plane."



 



>From my perspective the first part of the statement is not totally
complete, since the forwarding table entries also have to provide
mapping information
between MAC addresses and local VAPs, not only L3 tunnel destination
addresses. 



Agreed. This is actually mentioned in the following sentence that you
quoted.



For clarity, the sentence could be changed as:



 



"Forwarding table entries provide mapping information between MAC
addresses, VAPs, and L3 tunnel destination addresses."





 



In the same section it states further:
"In the absence of a management or control plane, data plane learning
MUST be used to populate forwarding tables. As frames arrive from VAPs
or from overlay tunnels, standard MAC learning procedures are used: The
source MAC address is learned against the VAP or the NVO3 tunnel on
which the frame arrived."



 



I do not really understand how the source MAC address of a frame
received from an overlay tunnel can be learned against the L3 tunnel
destination address by an L2 NVI, since the Overlamodule would be able to learn 
this mapping as part of the decapsulation
process. This requires, however, the Overlay module to have access to an
L2 VNI's forwarding table in order to insert the forwarding entry. The
draft is not as precise here as it should be.



 



By the way, the same is also true for the reverse direction. When an L2
NVI needs to forward a frame to the Overlay module for encapsulation,
the Overlay module needs to have access to the L2 NVI's forwarding table
in order to build the overlay encapsulation header. This is only
possible when the forwarding table is shared between the L2 VNI and the
Overlay module. If this was the case, it would be enough for the L2 VNI
to pass the corresponding VN Context along with the frame to the Overlay
module. The Overlay module could then use the VN Context, e.g. the VNID,
to access the forwarding table of the right L2 VNI.
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to