idnits 2.17.1 draft-dong-idr-inter-as-te-link-distribution-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2014) is 3587 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5392' is mentioned on line 229, but not defined == Missing Reference: 'RFC5316' is mentioned on line 225, but not defined ** Obsolete undefined reference: RFC 5316 (Obsoleted by RFC 9346) == Missing Reference: 'RFC4272' is mentioned on line 222, but not defined == Missing Reference: 'RFC6952' is mentioned on line 233, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-05 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 1, 2015 June 30, 2014 7 BGP Extensions for Inter-AS Traffic Engineering (TE) Link Distribution 8 draft-dong-idr-inter-as-te-link-distribution-00 10 Abstract 12 Protocol extensions to Interial Gataway Protocols (IGPs) have been 13 specified for the flooding of Traffice Engineering (TE) information 14 of the Inter-Autonomous System (AS) links into the local AS (RFC 5392 15 and RFC 5316), in which some information of the inter-AS links needs 16 to be manually configured. This document proposes BGP extensions for 17 dynamic advertisement of TE information of Inter-AS links between 18 adjacent ASes. Such mechanism may also be used for the distribution 19 of Inter-AS TE link information to some external entities, such as 20 Path Computation Element (PCE). 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 1, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Carrying Inter-AS Link Information in BGP . . . . . . . . . . 3 64 3. Operational Considerations . . . . . . . . . . . . . . . . . 4 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 6.2. Informaltive References . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 Protocol extensions to Interial Gataway Protocols (IGPs) have been 75 specified for the flooding of Traffic Engineering (TE) information of 76 the Inter-Autonomous System (AS) links in local AS [RFC5392] 77 [RFC5316]. With those IGP extension mechanisms, some of the TE 78 information of the inter-AS links, such as remote AS number and 79 remote AS Border Router (ASBR) IDs are manually configured on the 80 ASBRs of local AS. This requires additional human intervention and 81 may be error-prone. Besides, an ASBR of local AS needs to generate a 82 local link-state information for the inter-AS TE link, and also needs 83 to 'proxy' for the remote ASBR to generate an additional link-state 84 information, in order for the two-way check of the Inter-AS link 85 during the path calculation. This introduces additional processing 86 on the ASBR of local AS and the 'proxy' information may be not quite 87 accurate. As bandwidth and other TE information of the Inter-AS 88 links are useful for establishing TE Label Switched Paths (LSPs) 89 across multiple ASes, such information needs to be dynamically 90 exchanged between the peering ASes. 92 This document specifies BGP extensions for dynamic advertisement of 93 Inter-AS TE link information between the adjacent ASes. This 94 mechanism may also be used for the distribution of Inter-AS TE link 95 information to some external entities, such as Path Computation 96 Element (PCE). 98 2. Carrying Inter-AS Link Information in BGP 100 The Inter-AS link information is advertised in BGP UPDATE messages 101 using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. 102 The Link-State NLRI defined in [I-D.ietf-idr-ls-distribution] is 103 extended to carry the Inter-AS link information. 105 A new Protocol-ID is defined in the Link-State NLRI: 107 o Protocol-ID = 7: Inter-AS, The NLRI information has been sourced 108 from an Inter-AS connection 110 And a new Sub-TLV is defined in the Node Descriptor Sub-TLVs: 112 Sub-TLV Code Point Description Length 113 TBD BGP Identifier 4 115 BGP Identifier is the 4-octet unsigned integer that indicates a BGP 116 speaker, as defined in [RFC4271] [RFC6286]. 118 The format of the link NLRI with Protocol-ID 7 is shown in the figure 119 below: 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+ 124 | Protocol-ID=7 | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Identifier | 127 | (64 bits) | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 // Local Node Descriptors (variable) // 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 // Remote Node Descriptors (variable) // 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 // Link Descriptors (variable) // 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Figure 1. Inter-AS Link NLRI 137 The "Local Node Descriptors" field MUST contain the "Autonomous 138 System" Sub-TLV defined in [I-D.ietf-idr-ls-distribution] to identify 139 the local AS number, and the "BGP Identifer" Sub-TLV defined in this 140 document to identify the local ASBR. 142 The "Remote Node Descriptors" field MUST contain the "Autonomous 143 System" Sub-TLV defined in [I-D.ietf-idr-ls-distribution] to identify 144 the remote AS number, and the "BGP Identifer" Sub-TLV defined in this 145 document to identify the remote ASBR. 147 For IPv4 Inter-AS link, the "Link Descriptors" field MUST use "IPv4 148 interface address" Sub-TLV to specify the local IPv4 address, and use 149 "IPv4 neighbor address" Sub-TLV to specify the peering IPv4 address 150 on the remote ASBR. The local and peering addresses are the IPv4 151 addresses used for the specific EBGP session between the local and 152 remote ASBRs. 154 For IPv6 Inter-AS link, the "Link Descriptors" field MUST use "IPv6 155 interface address" Sub-TLV to specify the local IPv6 address, and use 156 "IPv6 neighbor address" Sub-TLV to specify the peering IPv6 address 157 on the remote ASBR. The local and peering addresses are the IPv6 158 addresses used for the specific EBGP session between the local and 159 remote ASBRs. 161 The TE characteristics of the Inter-AS link, such as bandwidth, 162 Shared Risk Link Group (SRLG), IPv4/IPv6 TE Router ID, etc., SHOULD 163 be carried in the Link attribute TLVs of the BGP-LS attribute as 164 specified in [I-D.ietf-idr-ls-distribution]. No further extension to 165 the BGP-LS attribute is defined in this document. 167 3. Operational Considerations 169 The advertisement of Inter-AS TE link information SHOULD be 170 constrained to only between the adjacent ASes connected by the Inter- 171 AS link. BGP speakers SHOULD NOT advertise the Inter-AS TE link 172 information received from the peering AS to any other ASes. The ASBR 173 receiving the Inter-AS TE link information SHOULD redistribute such 174 information into the IGP of the local AS, using mechanisms defined in 175 [RFC5392] and [RFC5316]. 177 The Inter-AS TE link information may optionally be advertised to an 178 external entity, for example PCE. Such advertisement SHOULD be 179 performed under agreement and policy control of the involved 180 administrative domains. 182 4. IANA Considerations 184 IANA needs to assign one new Protocol-ID for "Inter-AS" from the BGP- 185 TE/LS registry of Protocol-IDs. 187 IANA needs to assign one new Sub-TLV for "BGP Identifier" from the 188 "node anchor, link descriptor and link attribute TLVs" registry. 190 5. Security Considerations 192 Procedures and protocol extensions defined in this document do not 193 affect the BGP security model. See the Security Considerations 194 section of [RFC4271] for a discussion of BGP security. Also refer to 195 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 197 6. References 199 6.1. Normative References 201 [I-D.ietf-idr-ls-distribution] 202 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 203 Ray, "North-Bound Distribution of Link-State and TE 204 Information using BGP", draft-ietf-idr-ls-distribution-05 205 (work in progress), May 2014. 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 211 Protocol 4 (BGP-4)", RFC 4271, January 2006. 213 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 214 "Multiprotocol Extensions for BGP-4", RFC 4760, January 215 2007. 217 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 218 Identifier for BGP-4", RFC 6286, June 2011. 220 6.2. Informaltive References 222 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 223 4272, January 2006. 225 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 226 Support of Inter-Autonomous System (AS) MPLS and GMPLS 227 Traffic Engineering", RFC 5316, December 2008. 229 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 230 Support of Inter-Autonomous System (AS) MPLS and GMPLS 231 Traffic Engineering", RFC 5392, January 2009. 233 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 234 BGP, LDP, PCEP, and MSDP Issues According to the Keying 235 and Authentication for Routing Protocols (KARP) Design 236 Guide", RFC 6952, May 2013. 238 Authors' Addresses 240 Jie Dong 241 Huawei Technologies 242 Huawei Campus, No. 156 Beiqing Rd. 243 Beijing 100095 244 China 246 Email: jie.dong@huawei.com 248 Mach(Guoyi) Chen 249 Huawei Technologies 250 Huawei Campus, No. 156 Beiqing Rd. 251 Beijing 100095 252 China 254 Email: mach.chen@huawei.com