idnits 2.17.1 draft-mirsky-6man-unified-id-sr-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 (February 26, 2018) is 2248 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) -- Looks like a reference, but probably isn't: '0' on line 166 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-08 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-04 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-15 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-11 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-24 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-12 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track P. Shaofu 5 Expires: August 30, 2018 ZTE Corporation 6 February 26, 2018 8 Unified Identifier in IPv6 Segment Routing Networks 9 draft-mirsky-6man-unified-id-sr-00 11 Abstract 13 Segment Routing architecture leverages the paradigm of source 14 routing. It can be realized in a network data plane by prepending 15 the packet with a list of instructions, a.k.a. segments. A segment 16 can be encoded as an Multi-Protocol Label Switching (MPLS) label, 17 IPv4 address or IPv6 address. Segment Routing can be applied in MPLS 18 data plane by encoding segments in MPLS label stack. It also can be 19 applied to IPv6 data plane by encoding list of segment identifiers in 20 IPv6 Segment Routing Extension Header (SRH). This document extends 21 the use of the SRH to segment identifiers encoded as MPLS label and 22 IPv4 address. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 30, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Conventions used in this document . . . . . . . . . . . . 3 60 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 61 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 62 2. Segment Routing Extension Header: Benefits and Challenges . . 3 63 3. Support of Multiple SID Lengths in IPv6 Segment Routing 64 Extension Header . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Egress SR Tunnel Node . . . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 Segment Routing architecture [I-D.ietf-spring-segment-routing] 76 leverages the paradigm of source routing. It can be realized in a 77 network data plane by prepending the packet with a list of 78 instructions, a.k.a. segment identifiers (SIDs). A segment can be 79 encoded as an Multi-Protocol Label Switching (MPLS) label, IPv4 80 address or IPv6 address. Segment Routing can be applied in MPLS data 81 plane by encoding 20-bits SIDs in MPLS label stack 82 [I-D.ietf-spring-segment-routing-mpls]. It also can be applied to 83 IPv6 data plane by encoding list of 128-bits SIDs in IPv6 Segment 84 Routing Extension Header (SRH) 85 [I-D.ietf-6man-segment-routing-header]. Applicability of 32-bits 86 SID, that may represent IPv4 address, has not been defined. 88 SR extensions to Interior Gateway Protocols (IGP), IS-IS 89 [I-D.ietf-isis-segment-routing-extensions], OSPF 90 [I-D.ietf-ospf-segment-routing-extensions], and OSPFv3 91 [I-D.ietf-ospf-ospfv3-segment-routing-extensions], defined how 92 20-bits and 32-bits SIDs advertised and bound to SR objects and/or 93 instructions. Extensions to BGP link-state address family 94 [I-D.ietf-idr-bgp-ls-segment-routing-ext] enabled propagation of 95 segment information of variable length via BGP. 97 This document extends the use of the SRH 98 [I-D.ietf-6man-segment-routing-header] to SIDs encoded as MPLS label 99 and IPv4 address. 101 1.1. Conventions used in this document 103 1.1.1. Terminology 105 SR: Segment Routing 107 SRH: Segment Routing Extension Header 109 MPLS: Multiprotocol Label Switching 111 MPLS-SR: Segment Routing in MPLS 113 SID: Segment Identifier 115 IGP: Interior Gateway Protocol 117 OAM: Operation, Administration and Maintenance 119 TE: Traffic Engineering 121 SRv6: Segment Routing in IPv6 123 1.1.2. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 2. Segment Routing Extension Header: Benefits and Challenges 133 Many functions related to Operation, Administration and Maintenance 134 (OAM) require identification of the SR tunnel ingress and the path, 135 constructed by segments, between the ingress and the egress SR nodes. 136 Combination of IPv6 encapsulation [RFC8200] and SRH 137 [I-D.ietf-6man-segment-routing-header], referred to as SRv6, comply 138 with this requirements while it is challenging when applying SR in 139 MPLS networks, also referred to as MPLS-SR. 141 On the other hand, size of IPv6 SID presents scaling challenge to use 142 topological instructions that define strict explicit traffic 143 engineered (TE) path in combination with service-based instructions. 145 At the same time, that is where MPLS-SR approach provides better 146 results due to smaller SID length. 148 [I-D.bryant-mpls-unified-ip-sr] addresses the scaling challenge by 149 using more compact SID encoding of MPLS-SR. Ability to address OAM 150 challenge characteristic to MPLS-SR is open for investigation. 152 3. Support of Multiple SID Lengths in IPv6 Segment Routing Extension 153 Header 155 In section 3 of [I-D.ietf-6man-segment-routing-header] SRH format has 156 been defined as presented in Figure 1 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Last Entry | Flags | Tag | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | | 166 | Segment List[0] (128 bits IPv6 address) | 167 | | 168 | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | | 171 | | 172 ... 173 | | 174 | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | | 177 | Segment List[n] (128 bits IPv6 address) | 178 | | 179 | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 // // 182 // Optional Type Length Value objects (variable) // 183 // // 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Figure 1: SRH format 188 This document defines the new field Size in the Flags field, 189 presented in Figure 2, as two-bits field with the following values: 191 0b00 - 128-bits SID; 192 0b01 - 20-bits SID; 194 0b10 - 32-bits SID 196 0b11 - reserved for future use. 198 When the value of the S field is 0b01, the 20-bit SID is encoded in 199 four octets and occupies the 20 rightmost bits. 201 0 1 2 3 4 5 6 7 202 +-+-+-+-+-+-+-+-+ 203 |U|P|O|A|H| S |U| 204 +-+-+-+-+-+-+-+-+ 206 Figure 2: Flags field format 208 Entries of the segment list in the SRH MUST be of the same length. 210 4. Theory of Operation 212 When the SRH is used to include 20-bits or 32-bits SIDs the ingress 213 and transit nodes of an SR tunnel act as described in Section 5.1 and 214 Section 5.2 of [I-D.ietf-6man-segment-routing-header] respectively. 216 4.1. Egress SR Tunnel Node 218 TBD 220 5. IANA Considerations 222 TBD 224 6. Security Considerations 226 This specification inherits all security considerations of 227 [I-D.ietf-spring-segment-routing] and 228 [I-D.ietf-6man-segment-routing-header]. 230 7. Acknowledgements 232 TBD 234 8. Normative References 236 [I-D.bryant-mpls-unified-ip-sr] 237 Bryant, S., Farrel, A., Drake, J., and J. Tantsura, "MPLS 238 Segment Routing in IP Networks", draft-bryant-mpls- 239 unified-ip-sr-03 (work in progress), October 2017. 241 [I-D.ietf-6man-segment-routing-header] 242 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 243 Field, B., daniel.voyer@bell.ca, d., 244 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 245 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 246 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 247 Header (SRH)", draft-ietf-6man-segment-routing-header-08 248 (work in progress), January 2018. 250 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 251 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 252 and M. Chen, "BGP Link-State extensions for Segment 253 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-04 254 (work in progress), January 2018. 256 [I-D.ietf-isis-segment-routing-extensions] 257 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 258 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 259 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 260 segment-routing-extensions-15 (work in progress), December 261 2017. 263 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 264 Psenak, P., Filsfils, C., Previdi, S., Gredler, H., 265 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 266 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 267 segment-routing-extensions-11 (work in progress), January 268 2018. 270 [I-D.ietf-ospf-segment-routing-extensions] 271 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 272 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 273 Extensions for Segment Routing", draft-ietf-ospf-segment- 274 routing-extensions-24 (work in progress), December 2017. 276 [I-D.ietf-spring-segment-routing] 277 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 278 Litkowski, S., and R. Shakir, "Segment Routing 279 Architecture", draft-ietf-spring-segment-routing-15 (work 280 in progress), January 2018. 282 [I-D.ietf-spring-segment-routing-mpls] 283 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 284 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 285 data plane", draft-ietf-spring-segment-routing-mpls-12 286 (work in progress), February 2018. 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, 290 DOI 10.17487/RFC2119, March 1997, 291 . 293 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 294 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 295 May 2017, . 297 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 298 (IPv6) Specification", STD 86, RFC 8200, 299 DOI 10.17487/RFC8200, July 2017, 300 . 302 Authors' Addresses 304 Greg Mirsky 305 ZTE Corp. 307 Email: gregimirsky@gmail.com 309 Peng Shaofu 310 ZTE Corporation 311 No.50 Software Avenue, Yuhuatai District 312 Nanjing 313 China 315 Email: peng.shaofu@zte.com.cn