idnits 2.17.1 draft-alston-idr-crh-bgp-signalling-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 (November 18, 2019) is 1620 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) == Unused Reference: 'I-D.bonica-6man-comp-rtg-hdr' is defined on line 233, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'I-D.alston-spring-crh-bgp-signalling' is defined on line 272, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-mpls' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 296, but no explicit reference was found in the text == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-08 ** Downref: Normative reference to an Experimental draft: draft-bonica-6man-comp-rtg-hdr (ref. 'I-D.bonica-6man-comp-rtg-hdr') == Outdated reference: A later version (-06) exists of draft-bonica-lsr-crh-isis-extensions-00 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-05 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing Group A. Alston 3 Internet-Draft D. Henriques 4 Intended status: Standards Track Liquid Telecom 5 Expires: May 21, 2020 R. Bonica 6 Juniper Networks 7 November 18, 2019 9 BGP Extensions for IPv6 Compressed Routing Header (CRH) 10 draft-alston-idr-crh-bgp-signalling-00 12 Abstract 14 This document describes a new BGP extension for signalling the 15 mapping between Segment Identifiers (SID's), as used by a SRm6 16 Compressed Routing Header (CRH) and the IPv6 Addresses they 17 represent. The extension defines both a new optional BGP attribute 18 to signal the Maximum SID Value (MSV) and a new Sub-Address Family 19 (SAFI) of the IPv6 Address family. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 21, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. SID Signalling . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. BGP Attribute . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. MP Reach Attribute . . . . . . . . . . . . . . . . . . . 3 60 3.3. NLRI Format . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. BGP Path Attributes . . . . . . . . . . . . . . . . . . . 5 63 4.2. Subsequent Address Family Identifiers (SAFI) Parameters . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 7.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Overview 73 The SRm6 Compressed Routing Header uses an ordered sequence of 74 segment identifiers (SID) to specify the end to end path a packet 75 should follow through the network. This allows for much smaller 76 header sizes than found in the SRH (Segment Routing Header), which 77 utilizes an ordered sequence of 128 bit IPv6 address to achieve the 78 same goal. In addition, this method prevents the overloading of the 79 IPv6 address space. 81 This results in the need to signal the mapping between the SIDs used 82 in the CRH and the IPv6 addresses they represent. While such 83 signalling can be achieved through IGP extensions 84 [I-D.bonica-lsr-crh-isis-extensions] in a single network domain, 85 circumstances may dictate that the SID to address mapping be signaled 86 both to systems that do not partake in the IGP used within that 87 network domain, and between autonomous systems. 89 It is envisaged that such signalling will be required to signal, 90 among other things, deep packet inspection systems and flow analysis 91 systems that need the ability to see the full path a packet is 92 traversing, while at the same time not necessarily partaking in the 93 IGP which would normally be used for such signalling. This also 94 allows signalling of SID to Address mapping in environments that do 95 not run an IGP capable of such signalling. 97 2. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 3. SID Signalling 107 3.1. BGP Attribute 109 This document describes a new BGP extension for signalling the 110 mapping between Segment Identifiers (SIDs) as used by an SRm6 111 Compressed Routing Header (CRH) and the IPv6 Addresses they 112 represent. 114 The extension defines both a new optional transitive attribute to 115 signal the SID size in Octets and a new Subsequent Address Family 116 Identifier (SAFI) of the IPv6 Address family. 118 The document defines a new BGP attribute which signals the maximum 119 size in octets of a CRH Segment Identifier (SID). The attribute MUST 120 be included in any BGP session carrying the CRH signalling SAFI. 121 Additionally a new attribute BGP Path Attribute code will need to be 122 assigned by IANA. 124 The attribute is comprised of a single octet, which signals the 125 maximum length in octets of the SIDs found in the Network Layer 126 Reachability Information (NLRI) section of the relevant MP-BGP 127 Attribute. 129 Since SIDs in the context of a compressed routing header can be 130 either 16bit of 32bit, the attribute value MUST be either 2 or 4 and 131 the attribute MUST be ignored if this is not the case. In the event 132 of the CRH signalling attribute not being present in a BGP Update 133 Message, any BGP Updates containing the CRH SAFI MUST be considered 134 malformed and should be ignored. 136 3.2. MP Reach Attribute 138 The format of the MP Reach Attribute utilized by the CRH SAFI is as 139 per [RFC4760]. The AFI MUST be set to 2, and the SAFI is currently 140 TBD (see Section 4.2). 142 The Nexthop field of the attribute contains no significance and is 143 maintained purely for compatibility. For standardization purposes we 144 maintain a next-hop length field of 16 which contains an arbitrary 145 value. Implementations MAY at their discretion use the originating 146 router ID, or 128 bit mapped equivalent, in this field for simple 147 identification of mapping source 149 3.3. NLRI Format 151 The format of the NLRI contained within the MP Reach Attribute is 152 comprised of a 16bit Length (2 octets) field, followed by a series of 153 repeating tuples. The length in octets of the first element of each 154 tuple is determined by the SID Length specified in the CRH signalling 155 attribute (Section 3.1). The second element of the tuple is an IPv6 156 address and MUST be 16 octets in length. The length of the NLRI can 157 be calculated as (SID Length+16)*N where N is the number of tuples 158 contained within the NLRI. 160 0 1 2 3 4 5 6 7 161 +-+-+-+-+-+-+-+-+ 162 | NLRI Length | 163 | 2 octets | 164 +-+-+-+-+-+-+-+-+ 165 | | 166 | SID 1 | 167 | (M octets) | 168 | | 169 +-+-+-+-+-+-+-+-+ 170 | | 171 | IPv6 Address 1| 172 | (16 octets) | 173 | | 174 +-+-+-+-+-+-+-+-+ 175 | | 176 | SID N | 177 | (N octets) | 178 | | 179 +-+-+-+-+-+-+-+-+ 180 | | 181 | IPv6 Address N| 182 | (16 octets) | 183 | | 184 +-+-+-+-+-+-+-+-+ 186 The CRH SAFI uses a new NLRI defined as follows: where M MUST be the 187 size in octets of the MSV signalled via BGP upon session 188 establishment and N specifies a given number of SID/IPv6 Address 189 pairings. 191 4. IANA Considerations 193 This document defines new Sub-TLVs in the following existing 194 registries: 196 o BGP Path Attributes 198 o Subsequent Address Family Identifiers (SAFI) Parameters 200 4.1. BGP Path Attributes 202 A new SAFI in the IANA registry for "Subsequent Address Family 203 Identifiers (SAFI) Parameters" will be required: 205 Codepoint Description Reference 206 ----------------------------------------------- 207 TBD SRm6 CRH This document 209 4.2. Subsequent Address Family Identifiers (SAFI) Parameters 211 A new SAFI in the IANA registry for "Subsequent Address Family 212 Identifiers (SAFI) Parameters" will be required: 214 Codepoint Description Reference 215 ----------------------------------------------- 216 TBD SRm6 CRH Signalling SAFI This document 218 5. Security Considerations 220 SRm6 CRH BGP Signalling is envisioned to be run within a trusted 221 domain. 223 Further aspects of security are TBD. 225 6. Acknowledgements 227 The authors wish to acknowledge Ben Roberts for his support. 229 7. References 231 7.1. Normative References 233 [I-D.bonica-6man-comp-rtg-hdr] 234 Bonica, R., Kamite, Y., Niwa, T., Alston, A., Henriques, 235 D., Jalil, L., So, N., Xu, F., Chen, G., Zhu, Y., Yang, 236 G., and Y. Zhou, "The IPv6 Compressed Routing Header 237 (CRH)", draft-bonica-6man-comp-rtg-hdr-08 (work in 238 progress), October 2019. 240 [I-D.bonica-lsr-crh-isis-extensions] 241 Kaneriya, P., Shetty, R., Hegde, S., and R. Bonica, "IS-IS 242 Extensions To Support The IPv6 Compressed Routing Header 243 (CRH)", draft-bonica-lsr-crh-isis-extensions-00 (work in 244 progress), May 2019. 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, 248 DOI 10.17487/RFC2119, March 1997, 249 . 251 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 252 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 253 DOI 10.17487/RFC4271, January 2006, 254 . 256 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 257 "Multiprotocol Extensions for BGP-4", RFC 4760, 258 DOI 10.17487/RFC4760, January 2007, 259 . 261 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 262 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 263 May 2017, . 265 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 266 (IPv6) Specification", STD 86, RFC 8200, 267 DOI 10.17487/RFC8200, July 2017, 268 . 270 7.2. Informative References 272 [I-D.alston-spring-crh-bgp-signalling] 273 Alston, A., Henriques, D., and R. Bonica, "BGP Extensions 274 for IPv6 Compressed Routing Header (CRH)", draft-alston- 275 spring-crh-bgp-signalling-01 (work in progress), July 276 2019. 278 [I-D.ietf-6man-segment-routing-header] 279 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 280 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 281 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 282 progress), October 2019. 284 [I-D.ietf-spring-segment-routing-mpls] 285 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 286 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 287 data plane", draft-ietf-spring-segment-routing-mpls-22 288 (work in progress), May 2019. 290 [I-D.ietf-spring-srv6-network-programming] 291 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 292 Matsushima, S., and Z. Li, "SRv6 Network Programming", 293 draft-ietf-spring-srv6-network-programming-05 (work in 294 progress), October 2019. 296 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 297 Label Switching Architecture", RFC 3031, 298 DOI 10.17487/RFC3031, January 2001, 299 . 301 Authors' Addresses 303 Andrew Alston 304 Liquid Telecom 305 Nairobi 306 Kenya 308 Email: Andrew.Alston@liquidtelecom.com 310 Daniam Henriques 311 Liquid Telecom 312 Johannesburg 313 South Africa 315 Email: daniam.henriques@liquidtelecom.com 317 Ron Bonica 318 Juniper Networks 319 Herndon, Virginia 20171 320 USA 322 Email: rbonica@juniper.net