Hello, Larry
Thanks for your quick response. See my comments inline below.
Have a nice weekend
Zu Qiang
From: Larry Kreeger (kreeger) [mailto:[email protected]]
Sent: Friday, August 30, 2013 6:43 PM
To: Zu Qiang; [email protected]; Thomas Narten; Black, David
Subject: Re: Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01
Hi Zu,
See my responses inline. - Larry
From: Zu Qiang <[email protected]<mailto:[email protected]>>
Date: Friday, August 30, 2013 12:30 PM
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, Larry Kreeger
<[email protected]<mailto:[email protected]>>, Thomas Narten
<[email protected]<mailto:[email protected]>>, David Black
<[email protected]<mailto:[email protected]>>
Subject: Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01
Hello,
Some questions and comments on this draft:
* The word "802.1Q trunk" and "VLAN trunk" is used in a few places. Is it
just a proprietary concept? If not, do we need a definition somewhere?
LK> No, this should be a standard trunk, but based on other discussions about
VLANs in the past, this really means C-VLANs (as opposed to an S-VLAN or
B-VLAN). I can clarify it to say C-VLAN.
[Zu Qiang] Good, C-VLAN is much better.
* 3.1.2: "When the VN is providing L3 forwarding, the NVE must have the
knowledge of the TS IP addresses." This is true if the L3VNI is embedded in the
NVE function which is facing the TS. However, some implementations may have the
L3VNI centralized in the DC. In this case, the NVE function is split, where the
L2VNI and the L3VNI function are located in different boxes. It may be better
to have clear description allows more generic network architecture.
LK> Our assumptions have always been that the overlays are initiated/terminated
at the edge of the underlay. If the L3 routing is centralized, then it isn't
really an L3 overlay, it is just an L2 overlay that connects a TS to a central
router which is also at the edge of the overlay, in which case it is not
implemented in the NVE.
[Zu Qiang] I do agree with the assumption. But even the a L3 routing function
is centralized, L3VNI is still implemented in the NVE. It is just not in the
same box of the L2VNI. Maybe it is better to make it clear in the text that in
the split case, the L3VNI must have the knowledge of the TS IP address.
* 4.2: The two ways of TS address discovery is for MAC address discovery?
IP address discovery or both? Do we allow the VM to inform the NVE directly at
VN address association? Can we cover it in the text as well?
LK> Our goal is the make the implementation of the VN completely hidden from
the TS (VM). There should be no requirement to modify the TS to participate in
address advertisement. There is also an issue of trust, we should try to avoid
trusting a TS to advertise its address.
[Zu Qiang] I do agree the impacts on TS shall be avoided. But why the TS
address advertisement is untrusted? For instance, if the NVE is playing the
role of subnet GW, is it allowed that a VM may send ARP message to advertise
its address? If TS address advertisement is untrusted, then the TS cannot be
trusted, meaning the data plane gleaning is also untrusted, right?
* 4.3: In the VNIC address disassociation procedure, it only cover the case
when the VM is removed from a VNIC. Do we need to cover the case where the VM
disassociates one of the addresses from the VNIC and informs the NVE?
LK> I don't think the address disassociation should come directly from the VM,
but you are correct that this is a missing scenario. Addresses associations
should be able to be added and/or removed while the VM/VNIC is still present. I
will add that.
[Zu Qiang] thanks.
* 4.3: For the case that VM mobility between different hypervisors under
the same NVE, it's right that notifying the NVA may be inefficient. But it
doesn't have to be disallowed, right? It shall be allowed to let the NVA to
keep the track of the VM mobility.
LK> Right, it should certainly be allowed, this can just be an optimization to
take a load off the NVA if nothing is changing with respect to tenant address
to NVE address mappings.
[Zu Qiang] thanks.
* 4.4: is the timer solution good enough for the case of address
misconfiguration? How the NVE knows there is an address misconfiguration or it
is VM mobility?
LK> The timer is just a way to implement the optimization of not notifying the
NVA when a VM moves and we don't have a pre-associate to tell us directly. It
is related to VNIC migration, and not related to address configuration. I'm
not sure what you are referring to.
[Zu Qiang] there may be the case that two VMs under different NVEs are
configured with the same address by mistake. In this case, the NVA may receive
the VM connections notifications from both NVEs. The notification may not be
received at same time. How should the NVA knows this is a VM mobility or a
misconfiguration? Do we need a procedure to cover that case?
Have a nice day
Zu Qiang
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
