idnits 2.17.1 draft-lp-lsr-bgp-algorithm-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 (March 29, 2021) is 1121 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: 'RFC2545' is mentioned on line 142, but not defined == Missing Reference: 'RFC4271' is mentioned on line 142, but not defined == Missing Reference: 'RFC7911' is mentioned on line 166, but not defined == Unused Reference: 'I-D.zhou-idr-inter-domain-lcu' is defined on line 225, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-17) exists of draft-ietf-lsr-ip-flexalgo-00 == Outdated reference: A later version (-04) exists of draft-zhou-idr-inter-domain-lcu-02 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group Y. Liu 3 Internet-Draft Shaofu. Peng 4 Intended status: Standards Track ZTE Corporation 5 Expires: September 30, 2021 March 29, 2021 7 Advertisement of Algorithm in BGP 8 draft-lp-lsr-bgp-algorithm-00 10 Abstract 12 This document proposes extensions to BGP to support algorithm-based 13 end-to-end path establishment. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 30, 2021. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions used in this document . . . . . . . . . . . . . . 2 51 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 52 3. Algorithm Extended Community . . . . . . . . . . . . . . . . 2 53 4. Algo-based Inter-domain Path . . . . . . . . . . . . . . . . 3 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 58 7.2. Informative References . . . . . . . . . . . . . . . . . 5 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 61 1. Introduction 63 [I-D.ietf-lsr-flex-algo] proposes a solution that allows IGPs 64 themselves to compute constraint-based paths over the SR network. 65 [I-D.ietf-lsr-ip-flexalgo] allows flex-algo to be deployed in any IP 66 network, even in the absence of SR-MPLS and SRv6. 68 However, the algorithm-based path can only be used in the IGP domain. 69 In the BGP-based inter-domain scenario, end-to-end path based on 70 algorithms cannot be supported. 72 This document proposes extensions to BGP to support algorithm-based 73 end-to-end path establishment. 75 2. Conventions used in this document 77 2.1. Requirements Language 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in BCP 82 14 [RFC2119] [RFC8174] when, and only when, they appear in all 83 capitals, as shown here. 85 3. Algorithm Extended Community 87 This document defines a new transitive BGP Extended Communities 88 Attribute[RFC4360]. This new Extended Community has the following 89 encoding, where: 91 0 1 2 3 92 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 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | Type=0x03 | Sub-Type=TBA1 | Flags | Algorithm | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 ~ Reserved (4 Octets) ~ 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 Figure 1: Algorithm Extended Community 101 Type: 1 octet. The value is 0x03. 103 Sub-Type: 1 octet. TBA1 105 Flags: 1 octet. Unused, MUST be set to 0 and ingored on receipt. 107 Algorithm: 1 octet specifying IGP Algorithm Types. Value from 0 108 to 255. 110 Reserved: 4 Octets. MUST be set to 0, ignored at reception 112 4. Algo-based Inter-domain Path 114 +----------------------+ +----------------------+ 115 | | 2 | | | | 6 | | 116 | +---+ | | +---+ | 117 | | | | 118 | Flex-algo 128 | | Flex-algo 128 | 119 | | | | 120 |---+ +---+ +---+ +---| 121 | 1 |----------------| 4 |---------| 5 |----------------| 8 | 122 |---+ +---+ +---+ +---| 123 | | | | 124 | Flex-algo 129 | | Flex-algo 129 | 125 | | | | 126 | +---+ | | +---+ | 127 | | 3 | | | | 7 | | 128 +----------------------+ +----------------------+ 129 |<-----IGP Domain1---->| |<-----IGP Domain2---->| 131 Figure 2: Algo-based Inter-domain Path 133 As shown in Figure 2, node 8 is configured with two loopback 134 addresses, loopback-1 and loopback-2, they belong to the flex-algo 135 128 plane and the flex-algo 129 plane respectively. In IGP domain 2, 136 the routes to loopback-1 will be generated on the nodes (e.g, node 137 5,6,8) in the Flex-algo 128 plane and the routes to loopback-2 will 138 be generated on the nodes (e.g, node 5,7,8) in the Flex-algo 129 139 plane. 141 Node 5 can advertise prefix loopback-1 and prefix loopback-2 to node 142 4 through BGP[RFC2545][RFC4271]. Node 4 can import the BGP routes 143 into IGP and continue to advertise the routes to its neighbors in IGP 144 domain1. Or, node 4 directly advertises the routes to node 1 through 145 BGP. 147 In both cases, the corresponding algorithm information from IGP 148 domain2 is lost during the advertisement. As a result, node 4 does 149 not know which Flex-algo plane to import loopback-1 or loopback-2 150 into IGP domain 1. 152 With the Algorithm Extended Community, the algorithm information can 153 be carried in the BGP route of loopbacks advertised from node 5 to 154 node 4. 156 The administrator can configure algorithms in each IGP domain in the 157 network. A simple configuration method is that algorithms in each 158 IGP domain are consistent. If the algorithm configurations in each 159 IGP domain are inconsistent, the ASBR needs to know the mapping 160 relationship of the algorithms and carry the converted algorithm 161 information in Algorithm Extended Community when advertising the BGP 162 route. 164 A BGP speaker can advertise multiple paths for the same address 165 prefix, each path is identified by a Path Identifier in addition to 166 the address prefix [RFC7911]. By leveraging add-path, multiple 167 loopbacks on the egress node can be avoided. 169 Same approach is applicable for BGP Prefix SID advertisement[RFC8669] 170 and BGP Labeled Unicast(BGP-LU)[RFC8227]. If any Router Reflector 171 existed in the network, it SHOULD support this new Extended 172 Community. 174 5. Security Considerations 176 TBD 178 6. IANA Considerations 180 IANA is requested to allocate the sub-type TBA1 for "Algorithm 181 Extended Community" under the "BGP Transitive Opaque Extended 182 Community" 184 7. References 186 7.1. Normative References 188 [I-D.ietf-lsr-flex-algo] 189 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 190 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 191 algo-13 (work in progress), October 2020. 193 [I-D.ietf-lsr-ip-flexalgo] 194 Britto, W., Hegde, S., Kaneriya, P., Shetty, R., Bonica, 195 R., and P. Psenak, "IGP Flexible Algorithms (Flex- 196 Algorithm) In IP Networks", draft-ietf-lsr-ip-flexalgo-00 197 (work in progress), December 2020. 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, 201 DOI 10.17487/RFC2119, March 1997, 202 . 204 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 205 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 206 February 2006, . 208 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 209 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 210 May 2017, . 212 [RFC8227] Cheng, W., Wang, L., Li, H., van Helvoort, H., and J. 213 Dong, "MPLS-TP Shared-Ring Protection (MSRP) Mechanism for 214 Ring Topology", RFC 8227, DOI 10.17487/RFC8227, August 215 2017, . 217 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 218 A., and H. Gredler, "Segment Routing Prefix Segment 219 Identifier Extensions for BGP", RFC 8669, 220 DOI 10.17487/RFC8669, December 2019, 221 . 223 7.2. Informative References 225 [I-D.zhou-idr-inter-domain-lcu] 226 Chen, R., Dai, C., and S. Peng, "Inter-domain Network 227 Slicing via BGP-LU", draft-zhou-idr-inter-domain-lcu-02 228 (work in progress), January 2021. 230 Authors' Addresses 232 Liu Yao 233 ZTE Corporation 235 Email: liu.yao71@zte.com.cn 237 Peng Shaofu 238 ZTE Corporation 240 Email: peng.shaofu@zte.com.cn