I think the VRF lite text is ok. But, I agree with Thomas M. comments below about the MPLS text.
> Hi Thomas, > > Thomas Narten : > [..snip...] > > MPLS VRFs [RFC4364] 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 > > [RFC5036]) are used to set up the data path between PE and CE. > > > >Does that work? > > The above paragraph has a lot of issues: > - "MPLS VPNs" designate the service, "VRF" is the VPN-specific routing table > - the VRFs are not on CE devices, not on PEs > - there is no MPLS encapsulation between PE and CE, MPLS encapsulation > is used between PE routers > - LDP is not run between CE and PEs (is running between PE-P, P-P, but > not always, e.g. not when MPLS/GRE is used) > - a non-VPN IP routing protocol may be run between CEs and PEs (such as > BGP or OSPF), static routing is another possibility > (in the case where a carrier's-supporting-carrier approach is used, > things differ from the above, but this is not the typical deployment) > In addition, the text does not make clear that unlike VRF lite, BGP MPLS VPNs do not rely on multiple instances of routing protocols, but instead utilize a single control plane to advertise routes for all tenants while at the same time enabling overlapping IP addresses and tenant separation. >From the data path perspective, the most significant difference between the NVGRE/VXLAN type proposals and MPLSoverGRE is that the tenant identifier is global in the former and local in the latter. (ie in MPLSoGRE there is a control plane (BGP) for distributing labels (ie tenant separators) between service hops, while in the other proposals it is distributed globally and in the management plane). Dimitri > Thanks, > > -Thomas M. > > ______________________________________________________________________________ > ___________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages > that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
