idnits 2.17.1 draft-steinberg-6man-crh-vs-sr-mpls-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2020) is 1390 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-22 == Outdated reference: A later version (-05) exists of draft-filsfils-spring-sr-mpls-ipv6-control-plane-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN D. Steinberg, Ed. 3 Internet-Draft Lapishills Consulting Limited 4 Intended status: Informational W. Henderickx 5 Expires: December 31, 2020 Nokia 6 Z. Li 7 Huawei Technologies 8 W. Cheng 9 China Mobile 10 D. Voyer 11 Bell Canada 12 June 29, 2020 14 SR-MPLS over IPv6 satisfies CRH requirements 15 draft-steinberg-6man-crh-vs-sr-mpls-00 17 Abstract 19 SR-MPLS is a mature solution that provides highly scalable traffic 20 engineering capabilities in MPLS networks. This document analyzes 21 how SR-MPLS over IP exceeds the capabilities of the CRH, making the 22 latter redundant. 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 December 31, 2020. 41 Copyright Notice 43 Copyright (c) 2020 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 2. A Label by any Other Name . . . . . . . . . . . . . . . . . . 2 60 3. An Endpoint is an Endpoint . . . . . . . . . . . . . . . . . 3 61 4. All Roads Lead to Rome . . . . . . . . . . . . . . . . . . . 3 62 5. You Can't Manage What You Can't Measure . . . . . . . . . . . 3 63 6. MTU Overhead . . . . . . . . . . . . . . . . . . . . . . . . 3 64 7. Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 9.2. Informative References . . . . . . . . . . . . . . . . . 4 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 SR-MPLS [RFC8660] is a mature solution that provides highly scalable 74 traffic engineering capabilities in MPLS networks. 76 By encapsulating the MPLS label stack in an IPv4 or IPv6 [RFC4023], 77 or IP+UDP [RFC7510] header, an SR-MPLS policy can seamlessly traverse 78 IP-only routers in a network [RFC8663]. 80 The SR-MPLS control plane can run on top of IPv4 or IPv6. The latter 81 is reminded in [I-D.filsfils-spring-sr-mpls-ipv6-control-plane]. 83 This document analyzes how SR-MPLS over IP provides all the 84 capabilities of CRH [I-D.bonica-6man-comp-rtg-hdr], making CRH 85 redundant. 87 The analysis shows that the capabilities provided by CRH are in fact 88 a subset of the capabilities provided by SR-MPLS over IPv6. 90 2. A Label by any Other Name 92 [I-D.bonica-6man-comp-rtg-hdr] specifies the encoding of identifiers 93 in 16- or 32-bit values and places them in the CRH. The CRH is to be 94 inspected at each node represented by an identifier. 96 SR-MPLS over IP encodes identifiers in 20-bit values within 32 bit 97 labels and places them in an in the SR-MPLS or UDP header. 99 Because these encodings must translate into an action and a location 100 (IPv6 address) there is really no difference between these encodings, 101 in the end a 32-bit label is just a label that can identify anything 102 at an endpoint. 104 3. An Endpoint is an Endpoint 106 A node transmitting a packet containing a set of identifiers placed 107 within a CRH writes the IPv6 address of the first segment endpoint 108 into the destination address of the IPv6 header. 110 The same is true for SR-MPLS over IP, the source node writes the IPv6 111 address of the first segment endpoint into the destination address of 112 the IPv6 header. 114 There is no functional difference between the SR-MPLS over IP 115 endpoint vs the CRH endpoint, both receive a packet destined to their 116 interface and process the next segment. 118 4. All Roads Lead to Rome 120 At a segment endpoint the router receives the packet destined to it, 121 processes the next segment (MPLS label or CRH segment ID) and 122 rewrites the outer IPv6 header with a new destination address. The 123 CRH calls this table that maps labels to behavior and a destination 124 address a SFIB, however this is identical to the SR-MPLS label table. 126 Ultimately, the packet is received at the final destination within 127 the domain and the packets payload is processed. All roads do indeed 128 lead to Rome. 130 5. You Can't Manage What You Can't Measure 132 IP ping and traceroute just work for either SR-MPLS over IP or CRH. 134 SR-MPLS has a rich set of OAM mechanisms ([RFC8287]), and these 135 mechanisms are available for SR-MPLS over IP deployments. 137 CRH has no OAM defined for its labels. 139 6. MTU Overhead 141 Both SR-MPLS over IPv6 and CRH require an IPv6 header. However, due 142 to the overhead required for extension headers, CRH always results in 143 greater overhead in its 32 bit flavor vs SR-MPLS over IP. For the 144 CRH 16 bit flavor, SR-MPLS over IP still has a lower overhead for up 145 to 5 labels. 147 7. Services 149 MPLS has a rich set of services that are defined and translate into 150 MPLS labels. Protocols and SDN mechanisms to distribute these 151 service labelse are well known. 153 CRH has no service support, it is simply a transport header carrying 154 transport identifiers. It relies on other headers and identifiers to 155 provide services. 157 8. Conclusion 159 This analysis shows that CRH and the identifiers it carries do not 160 provide any demonstrable benefit beyond what SR-MPLS over IPv6 161 provides, in fact it can only support a subset of what SR-MPLS over 162 IPv6 is capable of. Furthermore, OAM is fully defined for SR-MPLS 163 and the control planes supporting SR-MPLS are mature and well 164 defined. 166 The conclusion is that there is no value in defining another header 167 to map labels to behaviors and IPv6 addresses within a domain. This 168 exists and it is SR-MPLS over IPv6. 170 9. References 172 9.1. Normative References 174 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 175 Decraene, B., Litkowski, S., and R. Shakir, "Segment 176 Routing with the MPLS Data Plane", RFC 8660, 177 DOI 10.17487/RFC8660, December 2019, 178 . 180 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 181 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 182 DOI 10.17487/RFC8663, December 2019, 183 . 185 9.2. Informative References 187 [I-D.bonica-6man-comp-rtg-hdr] 188 Bonica, R., Kamite, Y., Niwa, T., Alston, A., and L. 189 Jalil, "The IPv6 Compact Routing Header (CRH)", draft- 190 bonica-6man-comp-rtg-hdr-22 (work in progress), May 2020. 192 [I-D.filsfils-spring-sr-mpls-ipv6-control-plane] 193 Filsfils, C., Clad, F., and K. Talaulikar, "SR-MPLS Data 194 Plane with IPv6 Control Plane", draft-filsfils-spring-sr- 195 mpls-ipv6-control-plane-02 (work in progress), May 2020. 197 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 198 "Encapsulating MPLS in IP or Generic Routing Encapsulation 199 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 200 . 202 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 203 "Encapsulating MPLS in UDP", RFC 7510, 204 DOI 10.17487/RFC7510, April 2015, 205 . 207 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 208 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 209 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 210 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 211 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 212 . 214 Authors' Addresses 216 Dirk Steinberg (editor) 217 Lapishills Consulting Limited 218 Cyprus 220 Email: dirk@lapishills.com 222 Wim Henderickx 223 Nokia 224 Belgium 226 Email: wim.henderickx@nokia.com 228 Zhenbin Li 229 Huawei Technologies 230 China 232 Email: lizhenbin@huawei.com 233 Weiqiang Cheng 234 China Mobile 235 China 237 Email: chengweiqiang@chinamobile.com 239 Daniel Voyer 240 Bell Canada 241 Canada 243 Email: daniel.voyer@bell.ca