David,

My comments are inserted below:


For cross-VN communication, see Section 5.4 on Distributed Gateways, which also 
mentions inter-VN communication policies.
OTOH, that text does not point out that an NVA could configure the distributed 
gateway components; I agree that this should be noted.

[Linda] That is why I am asking the question. I don't think a simple note is 
enough. Typically cross subnet communication is done by IGP. If we want to use 
NVA to enforce the cross-subnet communication, we have to clarify how it is 
different from I2RS.

Speaking of 5.4 and 5.3, I find it is very confusing to mix the Gateway for VNs 
with the Gateway for the underlay networks, and mixing with the NVE function.

The Gateway for VNs can be simply described as routing traffic across different 
VNs. Conceptually, the Gateway for VNs is attached to NVE just like other VNs, 
even though the Gateway for VNs could be collocated on same device with  NVE 
component. When VN Gateway is collocated on a device with NVE, you can view 
this device having two logical components: VN Gateway & NVE.

It is easier to describe the VN Gateway function without mixing with the NVE 
function.



Both use of a distributed gateway and use of an NVA to configure it ought to be 
optional (although an NVA is clearly well-suited to configuring distributed 
gateway as it's already configuring much of the needed info into the NVEs).

[Linda] It is necessary to describe if a distributed Gateway node is capable of 
routing traffic among all VNs. If a distributed gateway node can only router 
traffic among a subset of VNs, it breaks the basic principle of RFC 1812. 
Therefore, more work/thought has to be put into it.


> IMHO, NVA is more close to DNS than to BGP. Instead of this "Federated NVAs", 
> why not examine today's DNS mechanism?

Because I'm rather short on "copious spare time."  If you have a concrete idea, 
feel free to elaborate ...

Thanks,
--David

From: Linda Dunbar [mailto:[email protected]]
Sent: Wednesday, October 30, 2013 7:00 PM
To: Thomas Narten; Black, David; 'Jon Hudson'; Larry Kreeger (kreeger); 
LASSERRE, MARC (MARC)
Cc: [email protected]
Subject: Comments to draft-narten-nvo3-arch-01

David, Thomas, Jon, Larry, and Marc,

The revised 01 draft is much better than the 00 version. However, I still have 
some comments, especially to Section 6:

Section 6: NVA:

I think it is necessary to describe the types of content on NVA.
Is NVA only responsible for Inner-outer mapping for target within same VN?
It is clear that each NVA has mapping for many VNs. But it is not clear if NVA 
is responsible cross VNs communication, or L3 forwarding among NVEs across the 
underlay network?

Is NVA also responsible for providing inter-VN communication policies?

E.g. For data packets from "a" (VN#1) to "b" (VN#2), if the NVE to which "a" is 
attached behaves as a gateway, this NVE has to terminate the MAC header of the 
data packets from "a", replace with a different MAC header for VN#2, and then 
add the NVO3 outer header. Does NVA provide the information to the NVE about 
VN#2's MAC header?

It is very good that the draft acknowledges the current interface between 
Orchestration systems to Hypervisor. As a matter fact, some server vendors 
require our network equipment to adapt to their existing interface. (E.g. 
Microsoft System Center wants to use their existing interface to hypervisor as 
the interface to the switched based encapsulation nodes (NVE) as well).

IMHO, NVA is more close to DNS than to BGP. Instead of this "Federated NVAs", 
why not examine today's DNS mechanism?

Linda


_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to