Network Working Group J. Dong Internet-Draft M. Chen Intended status: Standards Track Huawei Technologies Expires: January 1, 2015 June 30, 2014 BGP Extensions for Inter-AS Traffic Engineering (TE) Link Distribution draft-dong-idr-inter-as-te-link-distribution-00 Abstract Protocol extensions to Interial Gataway Protocols (IGPs) have been specified for the flooding of Traffice Engineering (TE) information of the Inter-Autonomous System (AS) links into the local AS (RFC 5392 and RFC 5316), in which some information of the inter-AS links needs to be manually configured. This document proposes BGP extensions for dynamic advertisement of TE information of Inter-AS links between adjacent ASes. Such mechanism may also be used for the distribution of Inter-AS TE link information to some external entities, such as Path Computation Element (PCE). 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]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 1, 2015. Dong & Chen Expires January 1, 2015 [Page 1] Internet-Draft BGP Extensions for Inter-AS TE June 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Carrying Inter-AS Link Information in BGP . . . . . . . . . . 3 3. Operational Considerations . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.2. Informaltive References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Protocol extensions to Interial Gataway Protocols (IGPs) have been specified for the flooding of Traffic Engineering (TE) information of the Inter-Autonomous System (AS) links in local AS [RFC5392] [RFC5316]. With those IGP extension mechanisms, some of the TE information of the inter-AS links, such as remote AS number and remote AS Border Router (ASBR) IDs are manually configured on the ASBRs of local AS. This requires additional human intervention and may be error-prone. Besides, an ASBR of local AS needs to generate a local link-state information for the inter-AS TE link, and also needs to 'proxy' for the remote ASBR to generate an additional link-state information, in order for the two-way check of the Inter-AS link during the path calculation. This introduces additional processing on the ASBR of local AS and the 'proxy' information may be not quite accurate. As bandwidth and other TE information of the Inter-AS links are useful for establishing TE Label Switched Paths (LSPs) across multiple ASes, such information needs to be dynamically exchanged between the peering ASes. Dong & Chen Expires January 1, 2015 [Page 2] Internet-Draft BGP Extensions for Inter-AS TE June 2014 This document specifies BGP extensions for dynamic advertisement of Inter-AS TE link information between the adjacent ASes. This mechanism may also be used for the distribution of Inter-AS TE link information to some external entities, such as Path Computation Element (PCE). 2. Carrying Inter-AS Link Information in BGP The Inter-AS link information is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The Link-State NLRI defined in [I-D.ietf-idr-ls-distribution] is extended to carry the Inter-AS link information. A new Protocol-ID is defined in the Link-State NLRI: o Protocol-ID = 7: Inter-AS, The NLRI information has been sourced from an Inter-AS connection And a new Sub-TLV is defined in the Node Descriptor Sub-TLVs: Sub-TLV Code Point Description Length TBD BGP Identifier 4 BGP Identifier is the 4-octet unsigned integer that indicates a BGP speaker, as defined in [RFC4271] [RFC6286]. The format of the link NLRI with Protocol-ID 7 is shown in the figure below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Protocol-ID=7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptors (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Remote Node Descriptors (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Link Descriptors (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Inter-AS Link NLRI The "Local Node Descriptors" field MUST contain the "Autonomous System" Sub-TLV defined in [I-D.ietf-idr-ls-distribution] to identify Dong & Chen Expires January 1, 2015 [Page 3] Internet-Draft BGP Extensions for Inter-AS TE June 2014 the local AS number, and the "BGP Identifer" Sub-TLV defined in this document to identify the local ASBR. The "Remote Node Descriptors" field MUST contain the "Autonomous System" Sub-TLV defined in [I-D.ietf-idr-ls-distribution] to identify the remote AS number, and the "BGP Identifer" Sub-TLV defined in this document to identify the remote ASBR. For IPv4 Inter-AS link, the "Link Descriptors" field MUST use "IPv4 interface address" Sub-TLV to specify the local IPv4 address, and use "IPv4 neighbor address" Sub-TLV to specify the peering IPv4 address on the remote ASBR. The local and peering addresses are the IPv4 addresses used for the specific EBGP session between the local and remote ASBRs. For IPv6 Inter-AS link, the "Link Descriptors" field MUST use "IPv6 interface address" Sub-TLV to specify the local IPv6 address, and use "IPv6 neighbor address" Sub-TLV to specify the peering IPv6 address on the remote ASBR. The local and peering addresses are the IPv6 addresses used for the specific EBGP session between the local and remote ASBRs. The TE characteristics of the Inter-AS link, such as bandwidth, Shared Risk Link Group (SRLG), IPv4/IPv6 TE Router ID, etc., SHOULD be carried in the Link attribute TLVs of the BGP-LS attribute as specified in [I-D.ietf-idr-ls-distribution]. No further extension to the BGP-LS attribute is defined in this document. 3. Operational Considerations The advertisement of Inter-AS TE link information SHOULD be constrained to only between the adjacent ASes connected by the Inter- AS link. BGP speakers SHOULD NOT advertise the Inter-AS TE link information received from the peering AS to any other ASes. The ASBR receiving the Inter-AS TE link information SHOULD redistribute such information into the IGP of the local AS, using mechanisms defined in [RFC5392] and [RFC5316]. The Inter-AS TE link information may optionally be advertised to an external entity, for example PCE. Such advertisement SHOULD be performed under agreement and policy control of the involved administrative domains. 4. IANA Considerations IANA needs to assign one new Protocol-ID for "Inter-AS" from the BGP- TE/LS registry of Protocol-IDs. Dong & Chen Expires January 1, 2015 [Page 4] Internet-Draft BGP Extensions for Inter-AS TE June 2014 IANA needs to assign one new Sub-TLV for "BGP Identifier" from the "node anchor, link descriptor and link attribute TLVs" registry. 5. Security Considerations Procedures and protocol extensions defined in this document do not affect the BGP security model. See the Security Considerations section of [RFC4271] for a discussion of BGP security. Also refer to [RFC4272] and [RFC6952] for analysis of security issues for BGP. 6. References 6.1. Normative References [I-D.ietf-idr-ls-distribution] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", draft-ietf-idr-ls-distribution-05 (work in progress), May 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP Identifier for BGP-4", RFC 6286, June 2011. 6.2. Informaltive References [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006. [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008. [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009. Dong & Chen Expires January 1, 2015 [Page 5] Internet-Draft BGP Extensions for Inter-AS TE June 2014 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013. Authors' Addresses Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Mach(Guoyi) Chen Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: mach.chen@huawei.com Dong & Chen Expires January 1, 2015 [Page 6]