Subject: [nvo3] Questions on draft-ietf-nvo3-dataplane-requirements-00

From: "Florian Mahr" <[email-masked]>
Date: Tue, 12 Feb 2013 13:39:25 +0100

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.

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.

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Tue, 12 Feb 2013 14:12:41 +0100

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-masked] [mailto:[email-masked]] On Behalf Of Florian Mahr
Sent: Tuesday, February 12, 2013 1:39 PM
To: [email-masked]
Subject: [nvo3] Questions on draft-ietf-nvo3-dataplane-requirements-00

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

---

From: "Black, David" <[email-masked]>
Date: Tue, 12 Feb 2013 12:19:53 -0500

> 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-masked] [mailto:[email-masked]] On Behalf Of LASSERRE, MARC (MARC)
Sent: Tuesday, February 12, 2013 8:13 AM
To: Florian Mahr; [email-masked]
Subject: Re: [nvo3] Questions on draft-ietf-nvo3-dataplane-requirements-00

Hi Florian,

Thanks,
Marc

---

From: "Florian Mahr" <[email-masked]>
Date: Tue, 12 Feb 2013 20:58:59 +0100

Hi Marc,

In order to be independent of a particular implementation, I try to formulate the problem I see in a different way:

In order for the L2 VNI to be able to learn the source MAC address of a frame received from an overlay tunnel against the L3 tunnel destination address, the L2 VNI has to terminate the L3 overlay tunnel. However, as you describe in section 3.3 "Overlay Module", the Overlay Module performs the functions related to tunnel processing. Therefore, it is the Overlay Module's job to learn this mapping entry and not the job of the L2 VNI that does not deal with the tunneling functions at all.

Thanks,

Florian

>>> "LASSERRE, MARC (MARC)" <[email-masked]> 12.02.13 14.13 Uhr >>>

Hi Florian,

Thanks,

Marc

---

From: "Florian Mahr" <[email-masked]>
Date: Tue, 12 Feb 2013 21:15:04 +0100

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-masked]> 12.02.13 18.21 Uhr >>>

> 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-masked] [mailto:[email-masked]] On Behalf Of
LASSERRE, MARC (MARC)
Sent: Tuesday, February 12, 2013 8:13 AM
To: Florian Mahr; [email-masked]
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.

Thanks,

Marc

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Florian Mahr
Sent: Tuesday, February 12, 2013 1:39 PM
To: [email-masked]
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.

 

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

---

From: Eric Gray <[email-masked]>
Date: Fri, 22 Feb 2013 20:50:00 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Florian Mahr
Sent: Tuesday, February 12, 2013 3:15 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>> 12.02.13 18.21 Uhr >>>

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-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of LASSERRE, MARC (MARC)
Sent: Tuesday, February 12, 2013 8:13 AM
To: Florian Mahr; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] Questions on draft-ietf-nvo3-dataplane-requirements-00

Hi Florian,

Thanks,
Marc

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Florian Mahr
Sent: Tuesday, February 12, 2013 1:39 PM
To: [email-masked]<mailto:[email-masked]>
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].