Subject: [nvo3] VRFs [was Re: call for adoption: draft-narten-nvo3-overlay-problem-statement-02]

From: Lizhong Jin<[email-masked]>
Date: Thu, 5 Jul 2012 11:30:40 +0800

> Proposed new text:
> 
>          <t>
>       In the case of IP networks, many routers provide a Virtual
>           Routing and Forwarding (VRF) service commonly known as "VRF
>           Lite".  The same router operates multiple instances of
>           forwarding tables, one for each tenant. Each forwarding
>           table instance is populated separately via routing
>           protocols, and adjacent routers encapsulate traffic in a way
>           that identifies the tenant (e.g., using a VLAN tag). Each
>           VRF Lite instance provides address and traffic isolation.
>           The VRF Lite instance for each frame is selected based on
>           that tenant identification.
>         </t>
> 
>         <t>
>           VRF's are a pure routing construct and in VRF Lite do not
>           have end-to-end significance in the sense that the data
>           plane carries a VRF Lite instance selector on an end-to-end
>           basis. Instead, the VRF Lite instance to be used is
>           determined at each hop using a combination of incoming
>           interface and some information in the frame (e.g., local
>           VLAN tag).  Furthermore, the VRF Lite model has typically
>           assumed that a separate control plane (e.g., based on a
>           routing protocol) governs the population of each forwarding
>           table. Thus, the VRF Lite model assumes multiple, logically
>           independent control plane instances and has no specific tag
>           within a data frame to identify the VRF Lite instance for
>           that frame.
>         </t>
> 
>    <t>
>      MPLS VRFs <xref target="RFC4364"></xref> place the VRF
>      functionality on the CE and PE devices, using MPLS
>      encapsulation to preserve tenant separation between the CE
>      and PE devices. Control plane protocols (e.g.,
>      LDP<xref target="RFC5036"></xref>) are used to set up the
>      data path between PE and CE.
>    </t>
[Lizhong] One point for RFC4364 I see is: MPLS VPN [RFC4364] requires an 
unified control plane (MP-BGP), uses MPLS label to identify VN membership, 
and the MPLS label is locally significant and must be advertised to every 
remote peer. Then it is a bit difficult to connect two VNs with different 
control plane. E.g, if you want to connect one VPN with static label 
configuration to another VPN with MP-BGP signaling seamlessly, you should 
configure the labels for every Prefix/VPN statically at both sides.
If NVO3 allows different control planes to exist, then using the MPLS 
label to identify membership in [RFC4364] is not a good approach.

Thanks
Lizhong

> Does that work?
> Thomas