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 protected]> 12.02.13 14.13 >>> Uhr >>> 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 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
