Hi, In terms of terminology, while most of us are aware of the functionality of VRF-Lite; I am not aware that the term is standardized. VRF-Lite refers to a particular implementation terminology, while "Multi-VRF CE" is term used most frequently in IETF.
Kind regards, Truman On Tue, Jul 3, 2012 at 7:07 PM, Luyuan Fang (lufang) <[email protected]>wrote: > Thomas, > > The proposed new text does not work, most talk on VRF/VPN > function/operation are not correct. > Here are some points. > > - VRF is not a service - it stands for Virtual Routing and Forwarding > table. It is a table. > - VPN is the service assuming you are talking about. VPN - Virtual Private > Network. Yes, it is Virtual Network (VN) with routing isolation - so > "Private". > - VRF-Lite is a feature extended from BGP VPN base function to allow one > CE supports multiple VPNs. > - VRF-Lite only modify CE, and there is no "each hop" things performed as > described in your text. > - VRF-lite does not support all MPLS-VRF functionality: label exchange, > LDP adjacency, or labeled packets. > - To PE, there is no difference between using VRF-lite or using multiple > CEs. > > Thomas Morin made more good comments to you already. > > BTW, you mentioned that "...I didn't realize that MPLS had adopted the VRF > terminology...". This does not make any sense. > > VRF is part of MPLS/BGP VPN technology, it did not exist before. > VRF-Lite is one of the ways to configure CE. > > Luyuan > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Thomas Narten > > Sent: Tuesday, July 03, 2012 9:44 AM > > To: Stiliadis, Dimitrios (Dimitri) > > Cc: [email protected] > > Subject: [nvo3] VRFs [was Re: call for adoption: draft-narten-nvo3- > > overlay-problem-statement-02] > > > > "Stiliadis, Dimitrios (Dimitri)" <[email protected]> > > writes: > > > > > I believe that Section 3.1 needs to be significantly revised since it > > > has some confusing statements. I cannot support this draft without a > > > revision of this Section: > > > > I'll assume that since you didn't comment about the first two > > paragraphs (L2 VLAN stuff), you are OK with that text. > > > > > VRF's are a pure routing construct and do not have end-to-end > > > significance in the sense that the data plane carries a VRF > > > indicator on an end-to-end basis. > > > > You're right. When I wrote this text, I didn't realize that MPLS had > > adopted the VRF terminology. What the text refers to is what others > > have pointed out is known as VRF lite. > > > > Now I understand why this text produced such a backlash. :-) > > > > 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> > > > > Does that work? > > > > Thomas > > > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
