Hi Larry et al,
I read this draft and have following comments and suggestions:
Text in section 3.1.2:
Note that a MAC address is required even for a pure L3 VN service
because VNICs filter out frames with destination MAC addresses that
do not match the VNIC's address; Therefore, the NVE providing an L3
service must first encapsulate an IP packet in an Ethernet frame with
the VNIC's destination MAC before it is sent to the End Device
containing the VNIC.
-end
This description leads to a particular solution. VNIC should support both
internal and external NVE cases. In case of internal NVE, is that necessary?
Furthermore, for ucast IP packets, the NVE need to encapsulate an IP packet in
an Ethernet frame with the VNIC's destination MAC address; for a mcast IP
packet, the NVE should encapsulate the packet in an Ethernet frame with the
multicast MAC address, not the VNIC address and should not be filtered out.
Text in section 4
On the hypervisor-facing side of the NVE, a control plane protocol is
necessary to provide an NVE with the information it needs to provide
connectivity across the Virtual Network for a given VNIC.
Specifically, the Hypervisor (or Network Service Appliance) utilizing
an external NVE needs to "attach to" and "detach from" a VN, as well
as communicate the addresses within that VN that are reachable within
it.
-end
Suggested text:
On the hypervisor-facing side of the external NVE, a control plane protocol is
necessary to provide the information that the NVE needs in providing
connectivity across the Virtual Network for a given VNIC. For example,
the Hypervisor (or Network Service Appliance) utilizing
an external NVE needs to "attach to" and "detach from" a VN, as well
as communicate the reachable addresses within that VN.
-end
Text in section 4.1
In the previous figures, NVEs reside on an external networking device
(e.g. an access switch). When an NVE is external, a protocol is
needed between the End Device (e.g. Hypervisor) making use of the
external NVE and the external NVE in order to make the NVE aware of
the changing VN membership requirements of the Tenant Systems within
the End Device.
A key driver for using a protocol ...
-end
Some redundant text.
Suggested text:
When an NVE is external, a control plane protocol is
needed between the two devices. A key driver for using the protocol ...
-end
Text in 4.1
When a VN within a
VDC is instantiated within a particular administrative domain, it can
be allocated a VN Context which only the NVE needs to use. Once an
NVE receives a VN connect indication, the NVE needs a way to get a VN
Context allocated (or receive the already allocated VN Context) for a
given VN Name or ID (as well as any other information needed to
transmit encapsulated packets).
-end
I don't know what it means. Does the "VN context" here have the same means
defined in the framework document? It seems not to me.
Section 4.4 seems describe the situation when hypervisor and NVE are
co-located. Suggest describing the external NVE case.
"IAM" need to be replaced by "NVA"
Cheers,
Lucy
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
