idnits 2.17.00 (12 Aug 2021) /tmp/idnits12243/draft-shepherd-bier-standards-track-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 20, 2017) is 1606 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 199, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 203, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 208, but no explicit reference was found in the text == Unused Reference: 'RFC8279' is defined on line 213, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Shepherd, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational A. Dolganow 5 Expires: June 23, 2018 Nokia 6 December 20, 2017 8 Justification for BIER on Standards Track 9 draft-shepherd-bier-standards-track-00 11 Abstract 13 This document is intended to provide justification for re-chartering 14 the BIER Working Group as Standards Track, and to move all BIER WG 15 previously published documents to Standards Track. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 23, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. IP Multicast Challenges . . . . . . . . . . . . . . . . . . . 2 54 3. Benefits of BIER . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Trade Offs . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 5. Impact of BIER on the Forwarding Plane . . . . . . . . . . . 4 57 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 9. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 10.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 IER [RFC8279](Bit Index Explicit Replication) is an alternative 69 method of multicast forwarding. It does not require any multicast- 70 specific trees, and hence does not require any multicast-specific 71 tree building protocols. Due to the particular sensitivity of adding 72 new significant functionality into the data-plane, the BIER work 73 began progress as Experimental. The current status of the experiment 74 is documented in this draft and is intended to provide justification 75 for re-charting the BIER Working Group (WG) as Standards Track and to 76 move all published documents of the BIER WG to Standards Track. This 77 document will detail the benefits, problems, and trade-offs for using 78 BIER instead of traditional multicast forwarding mechanisms, as 79 required by the BIER WG Charter charter-ietf-bier-01 81 1.1. Requirements Language 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 2. IP Multicast Challenges 89 Current IP Multicast solutions require a tree-building control plane 90 to build and maintain end-to-end tree state per flow, impacting 91 router state capacity and network convergence times. Multi-point 92 tree building protocols are often considered complex to deploy and 93 debug and may include mechanics from legacy use-cases and/or 94 assumptions which no longer apply to the current use-cases. When 95 multicast services are transiting a provider network through an 96 overlay, the core network has a choice to either aggregate customer 97 state into a minimum set of core states resulting in flooding traffic 98 to unwanted network end-points, or to map per-customer, per-flow tree 99 state directly into the provider core state amplifying the network- 100 wide state problem. Though the value proposition of network 101 replication is high, the cost of deploying IP Multicast is often 102 considered too high to justify deployment. 104 3. Benefits of BIER 106 BIER is a radical simplification of IP Multicast. BIER has no tree- 107 building protocol. BIER has no end-to-end tree/flow state. BIER has 108 no RPF requirements. BIER packets follow the same path to a 109 destination as a unicast packet would take to the same destination. 110 BIER provides deterministic convergence times regardless of how many 111 (S,G)s are being transported through the BIER network. BIER can be 112 deployed in SDN-driven deployment models, that minimize protocols 113 required in a network as well by eliminating multicast protocols and 114 relying on IGP infrastructure or direct SDN programmability. 116 4. Trade Offs 118 BIER is intended to carry IP Multicast packets - though not 119 explicitly restricted to this - across an overlay. Therefore, BIER 120 is not end-to-end like IP Multicast. This isn't an inherent 121 tradeoff, but it does focus the scope of the solution and the 122 discussion. The lack of (S,G) state often comes up as a perceived 123 limitation. But considering IP Unicast does not have active flow 124 state in the Forwarding Information Base (FIB) of each node, the 125 expectation that Multicast needs flow state for debugging purposes is 126 more of an artifact of legacy solutions rather than a requirement. 127 Debugging individual flows in BIER will require unicast techniques 128 such as flow export tools rather than forwarding state entries of IP 129 Multicast. BIER's primary limitation is the size of the bitmask. 130 The BIER architecture requires 256 bit mask support, but can 131 accommodate larger and smaller masks. As the masks get larger (+1024 132 bits) transport tax begins to exceed what is reasonable. 256 to 1024 133 end nodes of a BIER domain could then be considered a limitation. 134 Larger numbers of end nodes can be addressed with the use of BIER 135 Sets or via multiple BIER domains. 137 Because BIER is a forwarding plane feature significantly different 138 from IP Unicast or Multicast, not all routers today can be programmed 139 to support BIER. Transition mechanisms have already been introduced 140 to facility migration to an expanding BIER domain. 142 5. Impact of BIER on the Forwarding Plane 144 Bitmask forwarding techniques have been used in embedded systems and 145 software communication for decades. BIER is the first time the 146 mechanism has been extended to address distributed forwarding and 147 replication across a network. Though the BIER forwarding rules are 148 different than IP forwarding, it is significantly simpler than IP 149 Multicast forwarding. Detailed description of BIER forwarding is 150 documented in RFC8279. The BIER forwarding logic is simple, and the 151 state requirements minimal enough, that some existing micro-codable 152 forwarding hardware is programmable to support BIER today. It is 153 expected that dedicated BIER forwarding hardware will be developed to 154 extend the solution beyond micro-codable forwarding hardware - that 155 is expected to then further reduce hardware costs. Multiple router 156 vendors and chip vendors either have plans to support BIER or will be 157 announcing new products with BIER support very soon. In addition, 158 multiple operators are now actively evaluating and planning the 159 deployment of BIER for multicast delivery in their networks. This 160 validates BIER as next generation technology for multicast delivery. 162 6. Conclusion 164 The overall benefits of BIER over traditional IP Multicast are quite 165 significant, and the value of network replication is so well 166 understood, that operator and vendor engagement and support for BIER 167 was strong from the beginning and has only grown over time. It is 168 expected that BIER adoption will begin to take over as the dominant 169 network replication transport in all networks where traditional IP 170 Multicast is used today. It is our recommendation that the BIER work 171 and all existing BIER published RFCs be moved from the Experimental 172 track to the Standards track. 174 7. Acknowledgements 176 TBD 178 8. IANA Considerations 180 This memo includes no request to IANA. 182 9. Security Considerations 184 This draft is Informational and has no impact on security. 186 10. References 188 10.1. Normative References 190 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 10.2. Informative References 199 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 200 DOI 10.17487/RFC2629, June 1999, 201 . 203 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 204 Text on Security Considerations", BCP 72, RFC 3552, 205 DOI 10.17487/RFC3552, July 2003, 206 . 208 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 209 IANA Considerations Section in RFCs", RFC 5226, 210 DOI 10.17487/RFC5226, May 2008, 211 . 213 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 214 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 215 Explicit Replication (BIER)", RFC 8279, 216 DOI 10.17487/RFC8279, November 2017, 217 . 219 Authors' Addresses 221 Greg Shepherd (editor) 222 Cisco 223 San Jose 224 US 226 Email: gjshep@gmail.com 227 Anrew Dolganow 228 Nokia 229 438B Alexandra Road 08-07/10, Alexandra Technopark 230 119968 231 Singapore 233 Email: andrew.dolganow@nokia.com