RE: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have sent comments several times within NVO3 WG, but my comments hadn't been properly addressed.
 
So, I am sending them again; hopefully those comments can be addressed during the IETF last call.
 
NVO3 is about virtualization for data center (as stated in its charter statement). Inter-subnets communication (or inter Virtual Networks communication) is a big part (if not major part) of data centers traffic. Hosts in one subnet frequently communicate with hosts in different subnets or peers external to DC.
 
Yet the current framework draft focuses so much on encapsulating/decapsulating TS traffic, making NVO3 a lot like L2VPN or L3VPN MPLS network. Since IETF already has dedicated WGs for L2VPN and L3VPN, the NV03 WG should focus more on how inter-subnet communication is achieved in the overlay environment.
 
Here are the suggested changes:
 
-       The current Figure2 (Generic Reference model of NVo3) is like a clone to L2VPN. The NVO3 context reference model needs to add a gateway entity, as shown below, for relaying traffic from one VN to another VN.
                              _,....._
                           ,-'        `-.
                          /   External  `.
                         |     Network   |
                         `.             /
                           `.__     _,-'
                               `''''
                                  |
                             +---------+
                             | Gateway |
                             +----+----+
                             +----+----+
                             |   NVE   |
                             +-----+---+
       +--------+                  |                          +--------+
       | Tenant +--+               |                     +----| Tenant |
       | System |  |               |                    (')   | System |
       +--------+  |          ................         (   )  +--------+
                   |  +-+--+  .              .  +--+-+  (_)
                   |  | NVE|--.              .--| NVE|   |
                   +--|    |  .              .  |    |---+
                      +-+--+  .              .  +--+-+
                      /       .              .
 
 
-       There are good inter virtual network descriptions in http://datatracker.ietf.org/doc/draftyongnvo3frwkdpreqaddition/. The content from this draft should be included in the general framework, especially:
 
2.2. L2-3 NVE Providing IP Routing/Bridging-like Service (Framework Addition)
L2-3 NVE is similar to IRB function on a router [CIRB] device today. It supports the TSes attached to the NVE (locally or remotely) to communicate with each other when they are in a same route domain, i.e. a tenant virtual network. The NVE provides per tenant virtual switching and routing instance with address isolation and L3 tunnel encapsulation across the core. The L2-3 NVE supports the bridging among TSes that are on the same subnet and the routing among TSes that are on the different subnets.
 
 
 
-       Section 2.3.1. L2 NVE Providing Ethernet LAN-Like services:
Need to add a paragraph to address that great amount of traffic in DC is across VN (or across subnets).  Need to describe how across subnet is performed.  E.g. relayed at L2/L3 gateway.
 
-       Section 2.3.2. L3 NVE Providing IP/VRF-like forwarding
RFC4364 is about IP over MPLS network, i.e. the underlay is MPLS network. But NVO3’s underlay is IP.
 
-       Page 13 Second bullet: the text says that each VNI is automatically generated by the egress NVE. Isn’t each VNI supposed to match a local virtual network (e.g. represented by VLAN)? When the same NVE acts as Ingress NVE for the attached VMs, aren’t the VNI for ingress direction statically provisioned? Why need automatic egress VNI generation?
 
-       Section 3.2 Multi-homing: LAG is usually used to bundle multiple ports on one device. In the multi-homing environment, there are multiple NVEs. Besides, LAG and STP in the multi-homing environment can’t really prevent loop. You will need something like TRILL’s Appointed Forwarders to prevent loops in multi-homing environment.
 
 
Linda
-----Original Message-----
From: nvo3 [mailto:nvo3-bounces@xxxxxxxx] On Behalf Of The IESG
Sent: Wednesday, May 21, 2014 9:33 AM
To: IETF-Announce
Cc: nvo3@xxxxxxxx
Subject: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) to Informational RFC
 
 
The IESG has received a request from the Network Virtualization Overlays WG (nvo3) to consider the following document:
- 'Framework for DC Network Virtualization'
  <draft-ietf-nvo3-framework-06.txt> as Informational RFC
 
The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@xxxxxxxx mailing lists by 2014-06-04. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting.
 
Abstract
 
 
       This document provides a framework for Network Virtualization
       Overlays (NVO3) and it defines a reference model along with logical
       components required to design a solution.
 
 
 
 
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-nvo3-framework/
 
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-nvo3-framework/ballot/
 
 
No IPR declarations have been submitted directly on this I-D.
 
 
_______________________________________________
nvo3 mailing list
nvo3@xxxxxxxx
https://www.ietf.org/mailman/listinfo/nvo3
 

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]