idnits 2.17.1 draft-ietf-bier-non-mpls-bift-encoding-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 (April 13, 2018) is 2198 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Working Group IJ. Wijnands 3 Internet-Draft Cisco Systems 4 Intended status: Informational X. Xu 5 Expires: October 15, 2018 Alibaba Group 6 H. Bidgoli 7 Nokia 8 April 13, 2018 10 An Optional Encoding of the BIFT-id Field in the non-MPLS BIER 11 Encapsulation 12 draft-ietf-bier-non-mpls-bift-encoding-00 14 Abstract 16 Bit Index Explicit Replication (BIER) is an architecture that 17 provides optimal multicast forwarding through a "multicast domain", 18 without requiring intermediate routers to maintain any per-flow state 19 or to engage in an explicit tree-building protocol. The Multicast 20 packet is encapsulated using a BIER Header and transported through an 21 MPLS or non-MPLS network. When MPLS is used as the transport, the 22 Bit Indexed Forwarding Table (BIFT) is identified by a MPLS Label. 23 When non-MPLS transport is used, the BIFT is identified by a 20bit 24 value. This document describes one way of encoding the 20bit value. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 15, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 62 3. Specification of Requirements . . . . . . . . . . . . . . . . 3 63 4. The Bit Index Forwarding Table . . . . . . . . . . . . . . . 3 64 5. The Non-MPLS Static BIFT Encoding . . . . . . . . . . . . . . 4 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 68 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 74 that provides optimal multicast forwarding through a "multicast 75 domain", without requiring intermediate routers to maintain any per- 76 flow state or to engage in an explicit tree-building protocol. The 77 Multicast packet is encapsulated [RFC8296] using a BIER Header and 78 transported through an MPLS or non-MPLS network. When MPLS is used 79 as the transport, the Bit Indexed Forwarding Table (BIFT) is 80 identified by a MPLS Label. When non-MPLS transport is used, the 81 BIFT is identified by a 20bit value. This document describes one way 82 of encoding the 20bit value, based on the Sub-Domain (SD), Set 83 Identifier (SI) and BitStringLength (BSL) values. 85 The BIER architecture requires that a BFR has a BIFT for every 86 combination of that is being used. When processing a 87 BIER packet, the correct BIFT is inferred from the BIFT-id field of 88 the encapsulation. When the non-MPLS encapsulation is used in a 89 given BIER domain, it may be desirable for the a BIFT-id to be unique 90 in that domain. This document describes an OPTIONAL method that can 91 be used to form domain-wide unique BIFT-ids based on the triples. If in the future the BIER architecture is extented 93 with an additonal BIFT argument, this encoding does not generate 94 domain-wide unique idenifiers anymore. 96 This encoding, if used, is only for the convenience of the network 97 adminstrators. When forwarding a BIER packet, the BIFT-id is used as 98 an opaque 20-bit value that identifies a BIFT; the forwarding 99 procedures do not parse the 20-bit value, they just use it as a 100 lookup key. 102 2. Terminology and Definitions 104 Readers of this document are assumed to be familiar with the 105 terminology and concepts of the documents listed as Normative 106 References. For convenience, some of the more frequently used terms 107 appear below. 109 BIER: 110 Bit Indexed Explicit Replication. 112 BIFT-id: 113 Bit Indexed Forwarding Table Identifier. 115 3. Specification of Requirements 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 4. The Bit Index Forwarding Table 123 In MPLS networks a BIER label is allocated for each Bit Index 124 Forwarding Table (BIFT) from the platform specific, downstream label 125 database ([RFC8296]). This label is associated with a particular 126 combination of BIER Sub-Domain (SD), Set Identifier (SI) and 127 BitStringLength (BSL). In order for the network to know which MPLS 128 label represents a particular combination of , this 129 mapping has to be advertised through the network. This is currently 130 done through an IGP or BGP. In MPLS networks this is not a drawback 131 as the MPLS label has to be advertised anyway. 133 When the non-MPLS encoding is chosen, there is no need to advertise 134 the BIFT-id to mapping if the BIFT-id is domain-wide 135 unique. For this reason we're defining an encoding that MAY be used 136 by operators to compute the domain-wide unique BIFT-id values from 137 the SD, SI and BSL. Although the BIFT-id is not expected to change, 138 it may change when the BSL mismatch procedures [RFC8279] section 139 6.10.2 are applied. 141 5. The Non-MPLS Static BIFT Encoding 143 Find below the first 32 bits of the BIER header, encoding the SD, SI 144 and BSL into the 20 bit BIFT-id field. 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | BSL | SD | SI | TC |S| TTL | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 |-------- 20 bit BIFT-id Field ---------| 152 Figure 1 154 BSL: This 4-bit field encodes the length in bits of the BitString. 155 These are the same values as documented in [RFC8296]. 157 SD: This is a 8-bit field that encodes the Sub-Domain as described 158 in [RFC8279]. 160 SI: This is a 8-bit field that encodes the Set-ID as described in 161 [RFC8279]. 163 TC: This is a 3-bit field set to 000 (following [RFC8296]). 165 S: This is a 1-bit field set to 1 (following [RFC8296]). 167 TTL: See [RFC8296]. 169 6. Security Considerations 171 This document does not introduce any new security considerations 172 other than already discussed in [RFC8279]. 174 7. IANA Considerations 176 There is no IANA consideration. 178 8. Acknowledgments 180 The authors like to thank the following people for their comments and 181 contributions to this document; Eric Rosen, Neale Ranns, Jeffrey 182 Zhang. 184 9. Normative References 186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 187 Requirement Levels", BCP 14, RFC 2119, 188 DOI 10.17487/RFC2119, March 1997, 189 . 191 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 192 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 193 Explicit Replication (BIER)", RFC 8279, 194 DOI 10.17487/RFC8279, November 2017, 195 . 197 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 198 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 199 for Bit Index Explicit Replication (BIER) in MPLS and Non- 200 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 201 2018, . 203 Authors' Addresses 205 IJsbrand Wijnands 206 Cisco Systems 207 De Kleetlaan 6a 208 Diegem 1831 209 Belgium 211 Email: ice@cisco.com 213 Xiaohu Xu 214 Alibaba Group 216 Email: xiaohu.xxh@alibaba-inc.com 218 Hooman Bidgoli 219 Nokia 220 600 March Rd. 221 Ottawa, Ontario K2K 2E6 222 Canada 224 Email: hooman.bidgoli@nokia.com