Florian,
This might be quibbling.
Part of the association information is directly available in
one place in an implementation,
and part may be directly available in a different place within the same
implementation.
That does not mean that all of the information may not be
indirectly available at any place
in the implementation. In fact, I am reasonably certain that this is probably
the case in virtually all
implementations.
The question – from a high level – that weighs most in where we
claim this information is
required should be driven not by where it might be most easily learned in a
specific implementation,
but where it is needed.
I believe that is why the wording is as it is…
--
Eric
From: [email protected] [mailto:[email protected]] On Behalf Of Florian
Mahr
Sent: Tuesday, February 12, 2013 3:15 PM
To: [email protected]; [email protected]; [email protected];
[email protected]
Subject: [nvo3] Antw: RE: Questions ondraft-ietf-nvo3-dataplane-requirements-00
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]<mailto:[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]>
[mailto:[email protected]] On Behalf Of LASSERRE, MARC (MARC)
Sent: Tuesday, February 12, 2013 8:13 AM
To: Florian Mahr; [email protected]<mailto:[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]>
[mailto:[email protected]] On Behalf Of Florian Mahr
Sent: Tuesday, February 12, 2013 1:39 PM
To: [email protected]<mailto:[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 Overlay module already removed the overlay encapsulation
header before the frame is delivered to the L2 VNI. According to the NVE
reference model only the Overlay module 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
