draft-ietf-bess-virtual-subnet-06.txt   draft-ietf-bess-virtual-subnet-07.txt 
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational R. Raszuk Intended status: Informational C. Jacquenet
Expires: May 30, 2016 Bloomberg LP Expires: June 11, 2016 Orange
C. Jacquenet R. Raszuk
Orange
T. Boyes T. Boyes
Bloomberg LP Bloomberg LP
B. Fee B. Fee
Extreme Networks Extreme Networks
November 27, 2015 December 9, 2015
Virtual Subnet: A BGP/MPLS IP VPN-based Subnet Extension Solution Virtual Subnet: A BGP/MPLS IP VPN-based Subnet Extension Solution
draft-ietf-bess-virtual-subnet-06 draft-ietf-bess-virtual-subnet-07
Abstract Abstract
This document describes a BGP/MPLS IP VPN-based subnet extension This document describes a BGP/MPLS IP VPN-based subnet extension
solution referred to as Virtual Subnet, which can be used for solution referred to as Virtual Subnet, which can be used for
building Layer 3 network virtualization overlays within and/or building Layer 3 network virtualization overlays within and/or
between data centers. between data centers.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 30, 2016. This Internet-Draft will expire on June 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 33
3.7. ARP/ND Cache Table Scalability on Default Gateways . . . 10 3.7. ARP/ND Cache Table Scalability on Default Gateways . . . 10
3.8. ARP/ND and Unknown Unicast Flood Avoidance . . . . . . . 10 3.8. ARP/ND and Unknown Unicast Flood Avoidance . . . . . . . 10
3.9. Path Optimization . . . . . . . . . . . . . . . . . . . . 10 3.9. Path Optimization . . . . . . . . . . . . . . . . . . . . 10
4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Non-support of Non-IP Traffic . . . . . . . . . . . . . . 11 4.1. Non-support of Non-IP Traffic . . . . . . . . . . . . . . 11
4.2. Non-support of IP Broadcast and Link-local Multicast . . 11 4.2. Non-support of IP Broadcast and Link-local Multicast . . 11
4.3. TTL and Traceroute . . . . . . . . . . . . . . . . . . . 11 4.3. TTL and Traceroute . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
For business continuity purposes, Virtual Machine (VM) migration For business continuity purposes, Virtual Machine (VM) migration
across data centers is commonly used in situations such as data across data centers is commonly used in situations such as data
center maintenance, migration, consolidation, expansion, or disaster center maintenance, migration, consolidation, expansion, or disaster
avoidance. It's generally admitted that IP renumbering of servers avoidance. The IETF community has recognized that IP renumbering of
(i.e., VMs) after the migration is usually complex and costly at the servers (i.e., VMs) after the migration is usually complex and
risk of extending the business downtime during the process of costly. To allow the migration of a VM from one data center to
migration. To allow the migration of a VM from one data center to
another without IP renumbering, the subnet on which the VM resides another without IP renumbering, the subnet on which the VM resides
needs to be extended across these data centers. needs to be extended across these data centers.
To achieve subnet extension across multiple cloud data centers in a To achieve subnet extension across multiple cloud data centers in a
scalable way, the following requirements and challenges must be scalable way, the following requirements and challenges must be
considered: considered:
a. VPN Instance Space Scalability: In a modern cloud data center a. VPN Instance Space Scalability: In a modern cloud data center
environment, thousands or even tens of thousands of tenants could environment, thousands or even tens of thousands of tenants could
be hosted over a shared network infrastructure. For security and be hosted over a shared network infrastructure. For security and
skipping to change at page 11, line 29 skipping to change at page 11, line 29
according to the Virtual Subnet design, while non-IP traffic would be according to the Virtual Subnet design, while non-IP traffic would be
forwarded according to a particular Layer 2 VPN approach. Such forwarded according to a particular Layer 2 VPN approach. Such
unified L2/L3 VPN approach requires ingress PE routers to classify unified L2/L3 VPN approach requires ingress PE routers to classify
packets received from hosts before distributing them to the packets received from hosts before distributing them to the
corresponding L2 or L3 VPN forwarding processes. Note that more and corresponding L2 or L3 VPN forwarding processes. Note that more and
more cluster vendors are offering clustering applications based on more cluster vendors are offering clustering applications based on
Layer 3 interconnection. Layer 3 interconnection.
4.2. Non-support of IP Broadcast and Link-local Multicast 4.2. Non-support of IP Broadcast and Link-local Multicast
As illustrated before, intra-subnet traffic is forwarded at Layer 3 As illustrated before, intra-subnet traffic across PE routers is
in the Virtual Subnet solution. Therefore, IP broadcast and link- forwarded at Layer 3 in the Virtual Subnet solution. Therefore, IP
local multicast traffic cannot be supported by the Virtual Subnet broadcast and link-local multicast traffic cannot be forwarded across
solution. In order to support the IP broadcast and link-local PE routers in the Virtual Subnet solution. In order to support the
multicast traffic in the environment where the Virtual Subnet IP broadcast and link-local multicast traffic in the environment
solution has been deployed, the unified L2/L3 overlay approach as where the Virtual Subnet solution has been deployed, the unified L2/
described in Section 4.1 could be considered as well. That is, IP L3 overlay approach as described in Section 4.1 could be considered
broadcast and link-local multicast messages would be forwared at as well. That is, IP broadcast and link-local multicast messages
Layer 2 while routable IP traffic would be processed according to the would be forwared at Layer 2 while routable IP traffic would be
Virtual Subnet design. processed according to the Virtual Subnet design.
4.3. TTL and Traceroute 4.3. TTL and Traceroute
As mentioned before, intra-subnet traffic is forwarded at Layer 3 in As mentioned before, intra-subnet traffic is forwarded at Layer 3 in
the Virtual Subnet context. Since it doesn't require any change to the Virtual Subnet context. Since it doesn't require any change to
the Time To Live (TTL) handling mechanism of the BGP/MPLS IP VPN, the Time To Live (TTL) handling mechanism of the BGP/MPLS IP VPN,
when doing a traceroute operation on one host for another host when doing a traceroute operation on one host for another host
(assuming that these two hosts are within the same subnet but are (assuming that these two hosts are within the same subnet but are
attached to different sites), the traceroute output would reflect the attached to different sites), the traceroute output would reflect the
fact that these two hosts within the same subnet are actually fact that these two hosts within the same subnet are actually
connected via a Virtual Subnet, rather than a Layer 2 connection connected via a Virtual Subnet, rather than a Layer 2 connection
since the PE routers to which those two hosts are connected would be since the PE routers to which those two hosts are connected would be
displayed in the traceroute output. In addition, for any other displayed in the traceroute output. In addition, for any other
applications that generate intra-subnet traffic with TTL set to 1, applications that generate intra-subnet traffic with TTL set to 1,
these applications may not work properly in the Virtual Subnet these applications may not work properly in the Virtual Subnet
context, unless special TTL processing for such context has been context, unless special TTL processing and loop-prevention mechanisms
implemented (e.g., if the source and destination addresses of a for such context have been implemented. Details about such special
packet whose TTL is set to 1 belong to the same extended subnet, TTL processing and loop-prevention mechanisms are outside the scope
neither ingress nor egress PE routers should decrement the TTL of of this document.
such packet. Furthermore, the TTL of such packet should not be
copied into the TTL of the transport tunnel and vice versa).
5. Acknowledgements 5. Acknowledgements
Thanks to Susan Hares, Yongbing Fan, Dino Farinacci, Himanshu Shah, Thanks to Susan Hares, Yongbing Fan, Dino Farinacci, Himanshu Shah,
Nabil Bitar, Giles Heron, Ronald Bonica, Monique Morrow, Rajiv Asati, Nabil Bitar, Giles Heron, Ronald Bonica, Monique Morrow, Rajiv Asati,
Eric Osborne, Thomas Morin, Martin Vigoureux, Pedro Roque Marque, Joe Eric Osborne, Thomas Morin, Martin Vigoureux, Pedro Roque Marque, Joe
Touch and Wim Henderickx for their valuable comments and suggestions Touch, Wim Henderickx, Alia Atlas and Stephen Farrell for their
on this document. Thanks to Loa Andersson for his WG LC review on valuable comments and suggestions on this document. Thanks to Loa
this document. Thanks to Alvaro Retana for his AD review on this Andersson for his WG LC review on this document. Thanks to Alvaro
document. Thanks to Ronald Bonica for his RtgDir review. Thanks to Retana for his AD review on this document. Thanks to Ronald Bonica
Donald Eastlake for his Sec-DIR review of this document. Thanks to for his RtgDir review. Thanks to Donald Eastlake for his Sec-DIR
Jouni Korhonen for the OPS-Dir review of this document. Thanks to review of this document. Thanks to Jouni Korhonen for the OPS-Dir
Roni Even for the Gen-ART review of this document. Thanks to Sabrina review of this document. Thanks to Roni Even for the Gen-ART review
Tanamal for the IANA review of this document. of this document. Thanks to Sabrina Tanamal for the IANA review of
this document.
6. IANA Considerations 6. IANA Considerations
There is no requirement for any IANA action. There is no requirement for any IANA action.
7. Security Considerations 7. Security Considerations
Since the BGP/MPLS IP VPN signaling is reused without any change, Since the BGP/MPLS IP VPN signaling is reused without any change,
those security considerations as described in [RFC4364] are those security considerations as described in [RFC4364] are
applicable to this document. Meanwhile, since security issues applicable to this document. Meanwhile, since security issues
associated with the NDP are inherited due to the use of NDP proxy, associated with the NDP are inherited due to the use of NDP proxy,
those security considerations and recommendations as described in those security considerations and recommendations as described in
[RFC6583] are applicable to this document as well. [RFC6583] are applicable to this document as well.
Inter data-center traffic often carries highly sensitive information
at higher layers that is not directly understood (parsed) within an
egress or ingress PE. For example, migrating a VM will often mean
moving private keys and other sensitive configuration information.
For this reason inter data-center traffic should always be protected
for both confidentiality and integrity using a strong security
mechanism such as IPsec [RFC4301]. In future it may be feasible to
protect that traffic within the MPLS layer
[I-D.ietf-mpls-opportunistic-encrypt] though at the time of writing
the mechanism for that is not sufficiently mature to recommend.
Exactly how such security mechanisms are deployed will vary from case
to case, so securing the inter data-center traffic may or may not
involve deploying security mechanisms on the ingress/egress PEs or
further "inside" the data centers concerned. Note though that if
security is not deployed on the egress/ingress PEs there is a
substantial risk that some sensitive traffic may be sent in clear and
therefore be vulnerable to pervasive monitoring [RFC7258] or other
attacks.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925, [RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925,
DOI 10.17487/RFC0925, October 1984, DOI 10.17487/RFC0925, October 1984,
<http://www.rfc-editor.org/info/rfc925>. <http://www.rfc-editor.org/info/rfc925>.
[RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to
implement transparent subnet gateways", RFC 1027, implement transparent subnet gateways", RFC 1027,
skipping to change at page 13, line 15 skipping to change at page 13, line 32
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
2006, <http://www.rfc-editor.org/info/rfc4389>. 2006, <http://www.rfc-editor.org/info/rfc4389>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-mpls-opportunistic-encrypt]
Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
Networks", draft-ietf-mpls-opportunistic-encrypt-00 (work
in progress), July 2015.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for "BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
<http://www.rfc-editor.org/info/rfc4659>. <http://www.rfc-editor.org/info/rfc4659>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<http://www.rfc-editor.org/info/rfc4761>. <http://www.rfc-editor.org/info/rfc4761>.
skipping to change at page 14, line 5 skipping to change at page 14, line 29
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, Neighbor Discovery Problems", RFC 6583,
DOI 10.17487/RFC6583, March 2012, DOI 10.17487/RFC6583, March 2012,
<http://www.rfc-editor.org/info/rfc6583>. <http://www.rfc-editor.org/info/rfc6583>.
[RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution [RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution
Problems in Large Data Center Networks", RFC 6820, Problems in Large Data Center Networks", RFC 6820,
DOI 10.17487/RFC6820, January 2013, DOI 10.17487/RFC6820, January 2013,
<http://www.rfc-editor.org/info/rfc6820>. <http://www.rfc-editor.org/info/rfc6820>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
Authors' Addresses Authors' Addresses
Xiaohu Xu Xiaohu Xu
Huawei Technologies Huawei Technologies
No.156 Beiqing Rd No.156 Beiqing Rd
Beijing 100095 Beijing 100095
CHINA CHINA
Email: xuxiaohu@huawei.com Email: xuxiaohu@huawei.com
Christian Jacquenet
Orange
4 rue du Clos Courtel
Cesson-Sevigne, 35512
FRANCE
Email: christian.jacquenet@orange.com
Robert Raszuk Robert Raszuk
Bloomberg LP Bloomberg LP
731 Lexington Ave 731 Lexington Ave
New York City, NY 10022 New York City, NY 10022
USA USA
Email: robert@raszuk.net Email: robert@raszuk.net
Christian Jacquenet
Orange
4 rue du Clos Courtel
Cesson-Sevigne, 35512
FRANCE
Email: christian.jacquenet@orange.com
Truman Boyes Truman Boyes
Bloomberg LP Bloomberg LP
Email: tboyes@bloomberg.net Email: tboyes@bloomberg.net
Brendan Fee Brendan Fee
Extreme Networks Extreme Networks
Email: bfee@extremenetworks.com Email: bfee@extremenetworks.com
 End of changes. 14 change blocks. 
45 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/