Network Working Group Marko Kulmala Internet Draft Ville Hallivuori Tellabs Jyrki Soini TeliaSonera Expiration Date: January 2006 July 2005 Inter AS option for BGP/MPLS IP VPN draft-kulmala-l3vpn-interas-option-d-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes new Inter-AS option for RFC2547bis services. This option is a hydrid of options A and B that are defined in [2547BIS]. The proposed method can inter-operate seamlessly with a peer that is using rfc2547bis ch 10 option B inter-AS method. In this Inter AS option ASBR installs VPN-IPv4 routes into VRFs and acts as BGP next hop when it readvertises VPN-IPv4 routes with MP-BGP to other PE routers. This eliminates the need to LSP connectivity (or some other type of tunnels) between packet's ingress and egress PE. Since this option keeps VRFs it will give VPN context at ASBR and inherently provides route filtering based on Route Targets. This option is independent of the interconnecting media. Kulmala, et al. [Page 1] Internet Draft draft-kulmala-l3vpn-interAS-option-d-00.txt July 2005 Table of Contents 1 Specification of Requirements ......................... 2 2 Intellectual Property Statement ....................... 2 3 Introduction .......................................... 3 4 Inter AS option D definition ........................... 3 5 Inter AS option D characteristics ..................... 3 6 Security .............................................. 4 7 Quality of Service .................................... 4 8 Acknowledgments ....................................... 4 9 Intellectual Property Statement......................... 4 10 Full Copyright Statement .............................. 5 11 Normative References .................................. 5 12 Author Information .................................... 5 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 2. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Kulmala, et al. [Page 2] Internet Draft draft-kulmala-l3vpn-interAS-option-d-00.txt July 2005 3. Introduction Three Inter-AS options are defined in [2547BIS]. Option A is the only one that provides per VPN context (VRFs) at ASBR. The proposed option, called option D, provides VPN context and eliminates drawbacks of option A. The drawvbacs are: - dependency to the capability interconnecting media to provide multiple channels - per VRF BGP sessions In option D the interfaces between ASBRs are MPLS enabled and MP-BGP is used between ASes to distribute VPN-IPv4 addresses. 4. Inter AS option D definition This draft defines additional inter-AS MPLS VPN method. While the method is geared towards separating MPLS access networks to separate sub-ASs, it can also be used as generic inter-AS method. The proposed method can inter-operate seamlessly with a peer that is using rfc2547bis ch 10 option B inter-as method. Chapter 10 of draft-ietf-l3vpn-rfc2547bis-03.txt is amended with option D: d) EBGP redistribution of VRF routes as labeled VPN-IPv4 routes from AS to neighboring AS. In this procedure, the PE routers use IBGP to redistribute labeled VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector of which an ASBR is a client. The ASBR installs received routes to local VRFs using normal route-target based route selection. The ASBR then uses EBGP to re-advertise routes from VRFs as labeled VPN routes, with export route-targets and route-distinguisher of the VRF route is being advertised from, to the neighboring ASBR. Nexthop of the advertised routes is set to the advertising ASBR. The neighoring ASBR installs routes to local VRFs, and performs same re-export/re-advertisement procedure towards IBGP neighbors. 5. Inter AS option D characteristics Option D is a hydrid of options A and B. It enables the level of access to forwarded packets provided by the option A while removing the requirement of using per VRF peering sessions. Option D is agnostic to interconnecting media. Option D keeps customer routes in VRFs thus it inherently provides route filtering based on Route Targets. Option D allows ASBR to: -select QoS behaviour per VPN -aggregate VPN routes -execute VPN specific ACLs to forwarded packets -select PSN tunnels per VRF (end to end TE is possible) Kulmala, et al. [Page 3] Internet Draft draft-kulmala-l3vpn-interAS-option-d-00.txt July 2005 Option D hides core network structure (RTs and RDs) and enables load-balancing when multiple ASBRs are used. Option D eliminates the label switched path between the ingress and egress PE routers. 6. Security Security is at similar level than in option A in [2547BIS]. 7. Quality of Service IETF defined DS and DS-TE can be used. 8. Acknowledgments The authors wish to acknowledge the contributions of Paul Hallanoro, Heikki Heikkila and Jouni Tiainen. 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Kulmala, et al. [Page 4] Internet Draft draft-kulmala-l3vpn-interAS-option-d-00.txt July 2005 10. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 11. Normative References [2547BIS] "BGP/MPLS IP VPNs", Rosen, E, Rekhter, Y. draft-ietf-l3vpn-rfc2547bis-03.txt, October 2004. 12. Author Information Ville Hallivuori Tellabs Sinimaentie 6 FI-02630 Espoo, Finland e-mail: ville.hallivuori@tellabs.com Marko Kulmala Tellabs Sinikalliontie 7 FI-02630 Espoo, Finland e-mail: marko.kulmala@tellabs.com Jyrki Soini TeliaSonera P.O.Box 935 FI-00051 Sonera, Finland e-mail: jyrki.soini@teliasonera.com Kulmala, et al. [Page 5]