Networking Working Group JP. Vasseur, Ed. Internet-Draft Cisco Systems, Inc Intended status: Standards Track Gargi. Nalawade Expires: May 19, 2008 Red Back K. Kumaki KDDI Corporation November 16, 2007 An MP-BGP protocol extension to advertize TE-related PE-CE link information draft-vasseur-ccamp-ce-ce-te-03 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. This Internet-Draft will expire on May 19, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document proposes MP-BGP protocol extension so as to convey Traffic Engineering Link characterictics of PE (Provider Edge) - CE (Customer Edge) links in order to extend the visibility of the Traffic Engineering Database to those links. This can then be used Vasseur, et al. Expires May 19, 2008 [Page 1] Internet-Draft draft-vasseur-ccamp-ce-ce-te-03 November 2007 to more efficiently compute CE-to-CE Traffic Engineering Label Swtiched Path (TE LSP) when required to provide specific services such as bandwidth guarantees and end to end fast protection in a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) environment. Requirements Language 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 [RFC2119]. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Flooding of a "Physical" PE-CE link . . . . . . . . . . . . . 6 4. MP-BGP Protocol extensions . . . . . . . . . . . . . . . . . . 6 5. TED update . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Proposed Status and Discussion [To Be Removed Upon Publication] . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Vasseur, et al. Expires May 19, 2008 [Page 2] Internet-Draft draft-vasseur-ccamp-ce-ce-te-03 November 2007 1. Terminology Terminology used in this document LSR: Label Switch Router. BRPC: Backward Recursive Path Computation procedure. CE: Customer Edge. IGP Area: OSPF Area or IS-IS level. Inter-domain TE LSP: A TE LSP whose path transits across at least two different domains where a domain can either be an IGP area, an Autonomous System or a sub-AS (BGP confederations). NLRI: Network Layer Reachability Information. PCC: Path Computation Client: any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element: an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. PCEP: Path Computation Element Protocol. PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the PCE). PE: Provider Edge. RD: Route Distinguisher. SAFI: Subsequence Address Family Identifier. TED: Traffic Engineering Database which contains the topology and resource information of the domain. The TED may be fed by IGP extensions or potentially by other means. TE LSP: Traffic Engineering Label Switched Path. VSPT: Virtual Shortest Path Tree. 2. Introduction IGP extensions have been defined for OSPF (see [[RFC3630]) and for IS-IS (see [[RFC3784]) so as advertise Traffic Engineering link characteristics across an IGP area, which can then be used to compute Vasseur, et al. Expires May 19, 2008 [Page 3] Internet-Draft draft-vasseur-ccamp-ce-ce-te-03 November 2007 MPLS Traffic Engineering Label Switched Path (TE LSP). In Multiprotocol Label Switching Virtual Private Network (MPLS VPN) enabled networks ([[RFC4364]), IP connectivity is provided to customers sites by means VPNs enabled across an MPLS VPN network. Service Providers have been using constrained based routing using MPLS Traffic Engineering in their MPLS core between Provider Edge (PE) Label Switch Router (LSR) to carry the traffic between the PEs more optimaly and also to provide fast traffic restoration using a local protection technique such as Fast Reroute ([[RFC4090]]). In addition to IP connectivity services, Service Providers expressed the requirements to also be able to provide other services to VPN network based where Customer Edge (CE) routers could be interconnected via TE LSPs so as to offer CE-to-CE bandwidth guarantees, CE-to-CE protection (using a local protection recovery mechanism such as Fast Reroute [[RFC4090]]), and CE-to-CE path diversity. It must be noted that CE-to-CE path diversity may be required in order to load balance the flows while avoiding to affect all the traffic between the CEs upon the occurence of a single failure or when a global protection mechanism is used, in which case the second TE LSP is used as a backup should the primary TE LSP be affected by a failure. The provisioning of a CE-to-CE TE LSP can be seen as a particular instanciation of inter-domain MPLS Traffic Engineering whereby a TE LSP is computed across multiple routing domains. Thus, CE-to-CE TE LSP can be computed using either the per-domain path computation approach (described in [[I-D.ietf-ccamp-inter-domain-pd-path-comp]]) or a PCE-based path computation technique such as [[I-D.vasseur-pce-brpc]]. That said, the per-domain path computation technique may be suboptimal. Consider the following network: Vasseur, et al. Expires May 19, 2008 [Page 4] Internet-Draft draft-vasseur-ccamp-ce-ce-te-03 November 2007 CE1---PE1----P1----P2-----PE3----CE3 | | | | / PE2----P3----P4-----PE4--/ CE1, CE2 and CE3 belong to the same VPNx PE1, ..., PE4 are PEs routers P1, ..., P4 are P routers Objective is to compute a TE LSP T1 from CE1 to CE2 Figure 1 - An example of CE to CE TE LSP [I-D.ietf-ccamp-inter-domain-pd-path-comp] specifies a path computation technique whereby each path segment is being computed (on a per domain basis) during TE LSP signaling. In case of the example provided in figure 1, CE1 would compute the TE LSP up to PE1 (if PE1 is chosen as its prefered next-hop), then PE1 would select its best next hop PE and would compute the path segment up to that node and finally that last egress PE would compute the last path segment up to the destination CE. Altough such path computation allows for the computation of CE-to-CE TE LSP it cannot guarantee that the computed path is optimal (shortest constrained inter-domain TE LSP) and may lead to call admission failure due to the lack of TE information from the ingress to CE about the core network and from the ingress PE about the remote PE-CE link. Furthermore, the computation of a set of N diverse inter-domain paths is quite challenging. In contrast, PCE-based path computation techniques (see [[I-D.ietf-pce-architecture]]) have been defined that allows for the computation of shortest constrained inter-domain TE LSP, an particular instantiation of which is the CE-to-CE path computation. A Multi-PCE path computation technique has been described in [[I-D.vasseur-pce-brpc]] that can be used for the computation of such shortest constrained CE-to-CE TE LSP. Applying the BRPC procedure, a CE acting as a PCC (Path Computation Client) sends a path computation request of one of its attached PE acting as a PCE (in the form of a PCEP [[I-D.ietf-pce-pcep]] PCReq message, which in turn relays the PCReq message to the egress PE (also acting as a PCE). The shortest constrained CE-to-CE TE LSP would then be computed using the backward recursive scheme specifed in . [I-D.vasseur-pce-brpc]. In the particular context of CE-to-CE TE LSP, the BRPC procedure can be optimized by extending the TED visibility to some PE-CE links. Indeed, the knowledge of TE PE-CE link characteristics would allow the ingress PE (e.g. PE1) to compute in one pass the optimal (shortest) CE-to-CE TE LSP. Vasseur, et al. Expires May 19, 2008 [Page 5] Internet-Draft draft-vasseur-ccamp-ce-ce-te-03 November 2007 MP-BGP protocol extensions are proposed in this document to extend the TED visibility to some PE-CE links. 3. Flooding of a "Physical" PE-CE link This document specifies a BGP extension used to carry the TE information of a physical link between a PE and a CE. It MUST NOT be used to convey any form of aggregated traffic engineering information. 4. MP-BGP Protocol extensions A set of Traffic Engineering TLVs have been defined in [RFC3784] and [RFC3630] for ISIS and OSPF respectively. Furthermore other TE link attributes may be advertised using the TLV specified in [[I-D.ietf-isis-link-attr]]. No new TE TLVs are specified in this document and the existing TE TLVs will be re-used for the PE-CE link without any change. This document introduces a new SAFI called TE-Link SAFI [to be defined in a further revision of this document]. The NLRI of this SAFI is of the form RD:IP-address, where the RD is the RD of the VRF as described in [RFC4364] and the IP-address is the address of the CE router. The MP-BGP update for this SAFI will also be accompanied by extended community attribute carrying Export Route-targets as defined in [RFC4364]. This document also defines a new attribute called the TE attribute which carries the set of sub-TLVs defined in [RFC3784]. The format of the BGP TE attribute will be defined in a further revision of this document. 5. TED update The mode of operation described in this document requires to extend the TED so as to make it VPN-aware. That said, this does not require any protocol extensions per-say and will not be discussed in this document. The receipt of an MP-BGP update comprising a new BGP TE attribute will simply trigger a TED update should a TE-related information for a PE-CE link be changed. An implementation MAY use a threshold-based mechanisms to rate limit the frequency at which BGP updates will be sent (similarly to the IGP case). Vasseur, et al. Expires May 19, 2008 [Page 6] Internet-Draft draft-vasseur-ccamp-ce-ce-te-03 November 2007 6. Example An example is provided in this section that shows how the MP-BGP extensions defined in this document optimizes the BRPC path computation in the context of CE-to-CE TE LSP. Back to the exemplary network depicted in Figure 1. Step 1: The ingress CE (e.g. CE1) selects a PCE (say PE1). Step 2: Upon receiving the PCReq message from CE1, PE1 (acting as a PCE) determines the set S of PEs with a PE-CE link to the destination CE (e.g. CE2). The following VSPT is then computed: VSPT computed by the ingress PE acting as a PCE CE2 / \ PE1 PE2 Step 3: The shortest constrained path is then returned to CE1 in the form of a PCRep message (with loose hop). 7. IANA Considerations The SAFI code for the TE SAFI will be assigned by IANA. The BGP TE attribute code will also be assigned by the IANA. 8. Security Considerations This document raises no new security issues for BGP. 9. Acknowledgements 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Vasseur, et al. Expires May 19, 2008 [Page 7] Internet-Draft draft-vasseur-ccamp-ce-ce-te-03 November 2007 10.2. Informative References [I-D.ietf-ccamp-inter-domain-pd-path-comp] Vasseur, J., Ayyangar, A., and R. Zhang, "A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path-comp-06 (work in progress), November 2007. [I-D.ietf-ccamp-inter-domain-rsvp-te] Ayyangar, A., "Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain-rsvp-te-07 (work in progress), September 2007. [I-D.ietf-isis-link-attr] Vasseur, J. and S. Previdi, "Definition of an IS-IS Link Attribute sub-TLV", draft-ietf-isis-link-attr-03 (work in progress), February 2007. [I-D.ietf-pce-architecture] Farrel, A., "A Path Computation Element (PCE) Based Architecture", draft-ietf-pce-architecture-05 (work in progress), April 2006. [I-D.ietf-pce-pcep] Ayyangar, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path Computation Element (PCE) communication Protocol (PCEP)", draft-ietf-pce-pcep-09 (work in progress), November 2007. [I-D.vasseur-pce-brpc] Vasseur, J., "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths", draft-vasseur-pce-brpc-02 (work in progress), August 2006. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Vasseur, et al. Expires May 19, 2008 [Page 8] Internet-Draft draft-vasseur-ccamp-ce-ce-te-03 November 2007 May 2005. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. Appendix A. Proposed Status and Discussion [To Be Removed Upon Publication] This Internet-Draft is being submitted for eventual publication as an RFC with a proposed status of Standard. Discussion of this proposal should take place on the following mailing list: ccamp@ietf.org. Authors' Addresses JP Vasseur (editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: jpv@cisco.com Gargi Nalawade Red Back MA USA Email: gargi@redback.com Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460 JAPAN Email: ke-kumaki@kddi.com Vasseur, et al. Expires May 19, 2008 [Page 9] Internet-Draft draft-vasseur-ccamp-ce-ce-te-03 November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Vasseur, et al. Expires May 19, 2008 [Page 10]