As Robert pointed out, we need to distinguish between MPLS labels used in virtualization vs. MPLS protocols (LDP, RSVP-TE) used in data center transport networks.
The draft-fang-l3vpn-end-system-requirements-01 (sections 7 and 12) lists pros and cons of using MPLS vs. IP encapsulations. Multi-access technologies, especially Ethernet, might also be used in data center transport networks, specifically, 802.1ah "varieties." MPLS/BGP VPN control plane (RFC4364) is encapsulation agnostic as long as this encapsulation has the ability to carry a 20 bit label. Ø I don't see any good reason why MPLS-based DCVPN solutions (IPVPN, E-VPN) should be held back, particularly if the overlay tunnel is IP-based and MPLS > labels are used for VPN context, split-horizon, etc. I would not put MPLS/BGP VPN and EVPN quite on equal footing though for, at least, two main reasons: (1) MPLS/BGP VPN technology is the industry's de-facto standard for wide-area virtual networks and has been successfully deployed for 12+ years at large scale, while EVPN is still being defined; (2) MPLS/BGP VPN does not have the complexity of EVPN necessary for interoperability with bridging (such as split horizon requiring additional so called ESI MPLS labels, designated forwarder election, upstream assigned/context labels). Maria From: [email protected] [mailto:[email protected]] On Behalf Of Aldrin Isaac Sent: Sunday, December 09, 2012 12:52 AM To: Melinda Shore Cc: [email protected] Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 Historically there really was no MPLS enabled products that hit the right price points and/or features needed for the DC -- but some of us operators *have* implemented MPLS in the DC very successfully. My observation is that some vendors don't do MPLS/MPBGP very well and aggressively discourage its adoption, while other vendors reserve them for their SP products for which they need reasons to charge a premium. Now with support for MPLS in merchant silicon, I don't see any good reason why MPLS-based DCVPN solutions (IPVPN, E-VPN) should be held back, particularly if the overlay tunnel is IP-based and MPLS labels are used for VPN context, split-horizon, etc. On Thursday, November 29, 2012, Melinda Shore wrote: On 11/29/12 5:14 PM, S. Davari wrote: > Regarding Technical merits, all these solutions are technically > sound, the issue is that we don't want to have a dozen solution to > the same problem. Traditionally the IETF has let the market sort out competing technologies rather than try to deem one "best," but there's got to be at least some evidence that a technology will be adopted. I have to agree that MPLS in data centers is a tough sell. It would be great to see some input from data center operators to help sort this out. Melinda _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
