idnits 2.17.1 draft-ietf-bier-mpls-encapsulation-05.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 (July 8, 2016) is 2849 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: '1' on line 371 -- Looks like a reference, but probably isn't: '65535' on line 371 -- Looks like a reference, but probably isn't: '512' on line 157 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force IJ. Wijnands, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track E. Rosen, Ed. 5 Expires: January 9, 2017 Juniper Networks, Inc. 6 A. Dolganow 7 Nokia 8 J. Tantsura 9 Ericsson 10 S. Aldrin 11 Google, Inc. 12 I. Meilik 13 Broadcom 14 July 8, 2016 16 Encapsulation for Bit Index Explicit Replication in MPLS Networks 17 draft-ietf-bier-mpls-encapsulation-05 19 Abstract 21 Bit Index Explicit Replication (BIER) is an architecture that 22 provides optimal multicast forwarding through a "multicast domain", 23 without requiring intermediate routers to maintain any per-flow state 24 or to engage in an explicit tree-building protocol. When a multicast 25 data packet enters the domain, the ingress router determines the set 26 of egress routers to which the packet needs to be sent. The ingress 27 router then encapsulates the packet in a BIER header. The BIER 28 header contains a bitstring in which each bit represents exactly one 29 egress router in the domain; to forward the packet to a given set of 30 egress routers, the bits corresponding to those routers are set in 31 the BIER header. The details of the encapsulation depend on the type 32 of network used to realize the multicast domain. This document 33 specifies the BIER encapsulation to be used in an MPLS network. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 9, 2017. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. The BIER-MPLS Label . . . . . . . . . . . . . . . . . . . . . 3 70 3. BIER Header . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Imposing and Processing the BIER Encapsulation . . . . . . . 8 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 8. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 11 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 9.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 [BIER_ARCH] describes a new architecture for the forwarding of 84 multicast data packets. That architecture provides optimal 85 forwarding of multicast data packets through a "multicast domain". 86 However, it does not require any explicit tree-building protocol, and 87 does not require intermediate nodes to maintain any per-flow state. 88 That architecture is known as "Bit Index Explicit Replication" 89 (BIER). 91 This document will use terminology defined in [BIER_ARCH]. 93 A router that supports BIER is known as a "Bit-Forwarding Router" 94 (BFR). A "BIER domain" is a connected set of Bit-Forwarding Routers 95 (BFRs), each of which has been assigned a BFR-prefix. A BFR-prefix 96 is a routable IP address of a BFR, and is used by BIER to identify a 97 BFR. A packet enters a BIER domain at an ingress BFR (BFIR), and 98 leaves the BIER domain at one or more egress BFRs (BFERs). As 99 specified in [BIER_ARCH], each BFR of a given BIER domain is 100 provisioned to be in one or more "sub-domains". In the context of a 101 given sub-domain, each BFIR and BFER must have a BFR-id that is 102 unique within that sub-domain. A BFR-id is just a number in the 103 range [1,65535] that, relative to a BIER sub-domain, identifies a BFR 104 uniquely. 106 As described in [BIER_ARCH], BIER requires that multicast data 107 packets be encapsulated with a header that provides the information 108 needed to support the BIER forwarding procedures. This information 109 includes the sub-domain to which the packet has been assigned, a Set- 110 Id (SI), a BitString, and a BitStringLength. Together these values 111 identify the set of BFERs to which the packet must be delivered. 113 This document is applicable when a given BIER domain is both an IGP 114 domain and an MPLS network. In this environment, the BIER 115 encapsulation consists of two components: 117 o an MPLS label (which we will call the "BIER-MPLS label"); this 118 label appears at the bottom of a packet's MPLS label stack. 120 o a BIER header, as specified in Section 3. 122 Following the BIER header is the "payload". The payload may be an 123 IPv4 packet, an IPv6 packet, an ethernet frame, an MPLS packet, or an 124 OAM packet. If it is an MPLS packet, then an MPLS label stack 125 immediately follows the BIER header. The top label of this MPLS 126 label stack may be either a downstream-assigned label [RFC3032] or an 127 upstream-assigned label [RFC5331]. The BIER header contains 128 information (the Next Protocol field) identifying the type of the 129 payload. 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 2. The BIER-MPLS Label 137 As stated in [BIER_ARCH], when a BIER domain is also an IGP domain, 138 IGP extensions can be used by each BFR to advertise the BFR-id and 139 BFR-prefix. The extensions for OSPF are given in 140 [OSPF_BIER_EXTENSIONS]. The extensions for ISIS are given in 141 [ISIS_BIER_EXTENSIONS]. 143 When a particular BIER domain is both an IGP domain and an MPLS 144 network, we assume that each BFR will also use IGP extensions to 145 advertise a set of one or more "BIER-MPLS" labels. When the domain 146 contains a single sub-domain, a given BFR needs to advertise one such 147 label for each combination of SI and BitStringLength. If the domain 148 contains multiple sub-domains, a BFR needs to advertise one such 149 label per SI per BitStringLength for each sub-domain. 151 The BIER-MPLS labels are locally significant (i.e., unique only to 152 the BFR that advertises them) downstream-assigned MPLS labels. 153 Penultimate hop popping MUST NOT be applied to a BIER-MPLS label. 155 Suppose for example that there is a single sub-domain (the default 156 sub-domain), that the network is using a BitStringLength of 256, and 157 that all BFERs in the sub-domain have BFR-ids in the range [1,512]. 158 Since each BIER BitString is 256 bits long, this requires the use of 159 two SIs: SI=0 and SI=1. So each BFR will advertise, via IGP 160 extensions, two MPLS labels for BIER: one corresponding to SI=0 and 161 one corresponding to SI=1. The advertisements of these labels will 162 also bind each label to the default sub-domain and to the 163 BitStringLength 256. 165 As another example, suppose a particular BIER domain contains 2 sub- 166 domains (sub-domain 0 and sub-domain 1), supports 2 BitStringLengths 167 (256 and 512), and contains 1024 BFRs. A BFR that is provisioned for 168 both sub-domains, and that supports both BitStringLengths, would have 169 to advertise the following set of BIER-MPLS labels: 171 L1: corresponding to sub-domain 0, BitStringLength 256, SI 0. 173 L2: corresponding to sub-domain 0, BitStringLength 256, SI 1. 175 L3: corresponding to sub-domain 0, BitStringLength 256, SI 2. 177 L4: corresponding to sub-domain 0, BitStringLength 256, SI 3. 179 L5: corresponding to sub-domain 0, BitStringLength 512, SI 0. 181 L6: corresponding to sub-domain 0, BitStringLength 512, SI 1. 183 L7: corresponding to sub-domain 1, BitStringLength 256, SI 0. 185 L8: corresponding to sub-domain 1, BitStringLength 256, SI 1. 187 L9: corresponding to sub-domain 1, BitStringLength 256, SI 2. 189 L10: corresponding to sub-domain 1, BitStringLength 256, SI 3. 191 L11: corresponding to sub-domain 1, BitStringLength 512, SI 0. 193 L12: corresponding to sub-domain 1, BitStringLength 512, SI 1. 195 The above example should not be taken as implying that the BFRs need 196 to advertise 12 individual labels. For instance, instead of 197 advertising a label for and 198 a label for , a BFR could 199 advertise a contiguous range of labels (in this case, a range 200 containing exactly two labels) corresponding to . The first label in the range could correspond 202 to SI 0, and the second to SI 1. The precise mechanism for 203 generating and forming the advertisements is outside the scope of 204 this document. See [OSPF_BIER_EXTENSIONS] and 205 [ISIS_BIER_EXTENSIONS]. 207 Note that, in practice, labels only have to be assigned if they are 208 going to be used. If a particular BIER domain supports 209 BitStringLengths 256 and 512, but some sub-domain, say sub-domain 1, 210 only uses BitStringLength 256, then it is not necessary to assign 211 labels that correspond to the combination of sub-domain 1 and 212 BitStringLength 512. 214 When a BFR receives an MPLS packet, and the next label to be 215 processed is one of its BIER-MPLS labels, it will assume that a BIER 216 header (see Section 3) immediately follows the stack. It will also 217 infer the packet's sub-domain, SI, and BitStringLength from the 218 label. The packet's "incoming TTL" (see below) is taken from the TTL 219 field of the label stack entry that contains the BIER-MPLS label. 221 The BFR MUST perform the MPLS TTL processing correctly. If the 222 packet is forwarded to one or more BFR adjacencies, the BIER-MPLS 223 label carried by the forwarded packet MUST have a TTL field whose 224 value is one less than that of the incoming TTL. 226 Of course, if the incoming TTL is 1, the packet MUST be treated as a 227 packet whose TTL has been exceeded. The packet MUST NOT be 228 forwarded, but it MAY be passed to other layers for processing (e.g., 229 to cause an ICMP message to be generated, and/or to invoke BIER- 230 specific traceroute procedures, and/or to invoke other OAM 231 procedures.) 233 3. BIER Header 235 The BIER header is shown in Figure 1. This header appears after the 236 end of the MPLS label stack, immediately after the MPLS-BIER label. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |0 1 0 1| Ver | Len | Entropy | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | BitString (first 32 bits) ~ 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 ~ ~ 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 ~ BitString (last 32 bits) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 |OAM| Reserved | Proto | BFIR-id | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 1: BIER Header 254 First nibble: 256 The first 4 bits of the header are set to 0101; this ensures that 257 the BIER header will not be confused with an IP header or with the 258 header of a pseudowire packet. If a BFR receives a BIER packet 259 with any other value in the first nibble, it SHOULD discard the 260 packet and log an error. 262 Ver: 264 This 4-bit field identifies the version of the BIER header. This 265 document specifies version 0 of the BIER header. If a packet is 266 received by a particular BFR, and that BFR does not support the 267 specified version of the BIER header, the BFR MUST discard the 268 packet and log an error. 270 The value 0xF is reserved for experimental use; that value MUST 271 NOT be assigned by any future IETF document or by IANA. 273 Len: 275 This 4-bit field encodes the length in bits of the BitString. 277 Note: When parsing the BIER header, a BFR MUST infer the length of 278 the BitString from the BIER-MPLS label, not from the value of this 279 field. This field is present only to enable off-line tools (such 280 as LAN analyzers) to parse the BIER header. 282 If k is the length of the BitString, the value of this field is 283 log2(k)-5. However, only certain values are supported: 285 1: 64 bits 286 2: 128 bits 288 3: 256 bits 290 4: 512 bits 292 5: 1024 bits 294 6: 2048 bits 296 7: 4096 bits 298 The value of this field MUST NOT be set to any value other than 299 those listed above. A received packet containing another value in 300 this field SHOULD be discarded, and an error logged. If the value 301 in this field is other than what is expected based on the BIER- 302 MPLS label, the packet SHOULD be discarded and an error logged. 304 Entropy: 306 This 20-bit field specifies an "entropy" value that can be used 307 for load balancing purposes. The BIER forwarding process may do 308 equal cost load balancing, but the load balancing procedure MUST 309 choose the same path for any two packets have the same entropy 310 value. 312 If a BFIR is encapsulating (as the payload) MPLS packets that have 313 entropy labels, the BFIR MUST ensure that if two such packets have 314 the same MPLS entropy label, they also have the same value of the 315 BIER entropy field. 317 BitString: 319 The BitString that, together with the packet's SI, identifies the 320 destination BFERs for this packet. Note that the SI for the 321 packet is inferred from the BIER-MPLS label that precedes the BIER 322 header. 324 OAM: 326 These two bits are used for the passive performance measurement 327 marking method described in [PPM]. 329 Reserved: 331 These 10 bits are currently unused. They SHOULD be set to zero 332 upon transmission, and MUST be ignored upon reception. 334 Proto: 336 This 4-bit "Next Protocol" field identifies the type of the 337 payload. (The "payload" is the packet or frame immediately 338 following the BIER header.) The protocol field may take any of 339 the following values: 341 1: MPLS packet with downstream-assigned label at top of stack. 343 2: MPLS packet with upstream-assigned label at top of stack (see 344 [RFC5331]). If this value of the Proto field is used, the 345 BFR-id of the BFIR must be placed in the BFIR-id field. The 346 BFIR-id provides the "context" in which the upstream-assigned 347 label is interpreted. 349 3: Ethernet frame. 351 4: IPv4 packet. 353 5: OAM packet [BIER-OAM]. 355 6: IPv6 packet. 357 IANA is requested to set up a registry called "BIER Next Protocol 358 Identifiers", with the above values being assigned initially. 359 Values 0 and 15 are reserved. Values 7-14 are available for 360 assignment according to the Standards Action policy ([RFC5226] and 361 [RFC7120]). 363 If a BFER receives a BIER packet, but does not recognize (or does 364 not support) the value of the Next Protocol field, the BFER SHOULD 365 discard the packet and log an error. 367 BFIR-id: 369 By default, this is the BFR-id of the BFIR, in the sub-domain to 370 which the packet has been assigned. The BFR-id is encoded in the 371 16-bit field as an unsigned integer in the range [1,65535]. 373 Certain applications may require that the BFIR-id field contain 374 the BFR-id of a BFR other than the BFIR. However, that usage of 375 the BFIR-id field is outside the scope of the current document. 377 4. Imposing and Processing the BIER Encapsulation 379 When a BFIR receives a multicast packet from outside the BIER domain, 380 the BFIR carries out the following procedure: 382 1. By consulting the "multicast flow overlay" [BIER_ARCH], it 383 determines the value of the "Proto" field. 385 2. By consulting the "multicast flow overlay", it determines the set 386 of BFERs that must receive the packet. 388 3. If more than one sub-domain is supported, the BFIR assigns the 389 packet to a particular sub-domain. Procedures for determining 390 the sub-domain to which a particular packet should be assigned 391 are outside the scope of this document. 393 4. The BFIR looks up the BFR-id, in the given sub-domain, of each of 394 those BFERs. 396 5. The BFIR converts each such BFR-id into (SI, BitString) format, 397 as described in [BIER_ARCH]. 399 6. All such BFR-ids that have the same SI can be encoded into the 400 same BitString. Details of this encoding can be found in 401 [BIER_ARCH]. For each distinct SI that occurs in the list of the 402 packet's destination BFERs: 404 a. The BFIR makes a copy of the multicast data packet, and 405 encapsulates the copy in a BIER header (see Section 3). The 406 BIER header contains the BitString that represents all the 407 destination BFERs whose BFR-ids (in the given sub-domain) 408 correspond to the given SI. It also contains the BFIR's 409 BFIR-id in the sub-domain to which the packet has been 410 assigned. 412 N.B.: For certain applications, it may be necessary for the 413 BFIR-id field to contain the BFR-id of a BFR other than the 414 BFIR that is creating the header. Such uses are outside the 415 scope of this document, but may be discussed in future 416 revisions. 418 b. The BFIR then applies to that copy the forwarding procedure 419 of [BIER_ARCH]. This may result in one or more copies of 420 the packet (possibly with a modified BitString) being 421 transmitted to a neighboring BFR. 423 c. Before transmitting a copy of the packet to a neighboring 424 BFR, the BFIR finds the BIER-MPLS label that was advertised 425 by the neighbor as corresponding to the given SI, sub- 426 domain, and BitStringLength. An MPLS label stack is then 427 preprended to the packet. This label stack [RFC3032] will 428 contain one label, the aforementioned BIER-MPLS label. The 429 "S" bit MUST be set, indicating the end of the MPLS label 430 stack. The TTL field of this label stack entry is set 431 according to policy. The packet may then be transmitted to 432 the neighboring BFR. (This may result in additional MPLS 433 labels being pushed on the stack. For example, if an RSVP- 434 TE tunnel is used to transmit packets to the neighbor, a 435 label representing that tunnel would be pushed onto the 436 stack.) 438 When an intermediate BFR is processing a received MPLS packet, and 439 one of the BFR's own BIER-MPLS labels rises to the top of the label 440 stack, the BFR infers the sub-domain, SI, and BitStringLength from 441 the label. The BFR then follows the forwarding procedures of 442 [BIER_ARCH]. If it forwards a copy of the packet to a neighboring 443 BFR, it first swaps the label at the top of the label stack with the 444 BIER-MPLS label, advertised by that neighbor, that corresponds to the 445 same SI, sub-domain, and BitStringLength. Note that when this swap 446 operation is done, the TTL field of the BIER-MPLS label of the 447 outgoing packet MUST be one less than the "incoming TTL" of the 448 packet, as defined in Section 2. 450 Thus a BIER-encapsulated packet in an MPLS network consists of a 451 packet that has: 453 o An MPLS label stack with a BIER-MPLS label at the bottom of the 454 stack. 456 o A BIER header, as described in Section 3. 458 o The payload. 460 The payload may be an IPv4 packet, an IPv6 packet, an ethernet frame, 461 an MPLS packet, or an OAM packet. If it is an MPLS packet, the BIER 462 header is followed by a second MPLS label stack; this stack is 463 separate from the stack that precedes the BIER header. For an 464 example of an application where it is useful to carry an MPLS packet 465 as the BIER payload, see [BIER_MVPN]. 467 5. IANA Considerations 469 IANA is requested to set up a registry called "BIER Next Protocol 470 Identifiers", with the values indicated in Section 3 being assigned 471 initially. Values 0 and 15 are reserved. Values 7-14 are available 472 for assignment according to the Standards Action policy ([RFC5226], 473 [RFC7120].) 475 6. Security Considerations 477 As this document makes use of MPLS, it inherits any security 478 considerations that apply to the use of the MPLS data plane. 480 As this document makes use of IGP extensions, it inherits any 481 security considerations that apply to the IGP. 483 The security considerations of [BIER_ARCH] also apply. 485 7. Acknowledgements 487 The authors wish to thank Rajiv Asati, John Bettink, Nagendra Kumar, 488 Christian Martin, Neale Ranns, Greg Shepherd, Ramji Vaithianathan, 489 and Jeffrey Zhang for their ideas and contributions to this work. 491 8. Contributor Addresses 493 Below is a list of other contributing authors in alphabetical order: 495 Mach (Guoyi) Chen 496 Huawei 498 Email: mach.chen@huawei.com 500 Arkadiy Gulko 501 Thomson Reuters 502 195 Broadway 503 New York NY 10007 504 United States 506 Email: arkadiy.gulko@thomsonreuters.com 508 Wim Henderickx 509 Nokia 510 Copernicuslaan 50 511 Antwerp 2018 512 Belgium 514 Email: wim.henderickx@nokia.com 516 Martin Horneffer 517 Deutsche Telekom 518 Hammer Str. 216-226 519 Muenster 48153 520 Germany 522 Email: Martin.Horneffer@telekom.de 524 Uwe Joorde 525 Deutsche Telekom 526 Hammer Str. 216-226 527 Muenster D-48153 528 Germany 530 Email: Uwe.Joorde@telekom.de 532 Tony Przygienda 533 Juniper Networks, Inc. 534 1194 N. Mathilda Ave. 535 Sunnyvale, California 94089 536 United States 538 Email: prz@juniper.net 540 9. References 542 9.1. Normative References 544 [BIER_ARCH] 545 Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 546 and S. Aldrin, "Multicast using Bit Index Explicit 547 Replication", internet-draft draft-ietf-bier-architecture- 548 03, January 2016. 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, 552 DOI 10.17487/RFC2119, March 1997, 553 . 555 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 556 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 557 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 558 . 560 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 561 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 562 DOI 10.17487/RFC5226, May 2008, 563 . 565 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 566 Label Assignment and Context-Specific Label Space", 567 RFC 5331, DOI 10.17487/RFC5331, August 2008, 568 . 570 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 571 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 572 2014, . 574 9.2. Informative References 576 [BIER-OAM] 577 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 578 and G. Mirsky, "BIER Ping and Trace", internet-draft 579 draft-kumarzheng-bier-ping-03.txt, July 2016. 581 [BIER_MVPN] 582 Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 583 Dolganow, A., and T. Przygienda, "Multicast VPN Using 584 Bier", internet-draft draft-ietf-bier-mvpn-03, June 2016. 586 [ISIS_BIER_EXTENSIONS] 587 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 588 "BIER Support via ISIS", internet-draft draft-ietf-bier- 589 isis-extensions-02.txt, March 2016. 591 [OSPF_BIER_EXTENSIONS] 592 Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 593 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 594 for Bit Index Explicit Replication", internet-draft draft- 595 ietf-ospf-bier-extensions-02.txt, March 2016. 597 [PPM] Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T. 598 Mizrahi, "IP Flow Performance Measurement Framework", 599 draft-chen-ippm-coloring-based-ipfpm-framework-06 (work in 600 progress), March 2016. 602 Authors' Addresses 604 IJsbrand Wijnands (editor) 605 Cisco Systems, Inc. 606 De Kleetlaan 6a 607 Diegem 1831 608 Belgium 610 Email: ice@cisco.com 612 Eric C. Rosen (editor) 613 Juniper Networks, Inc. 614 10 Technology Park Drive 615 Westford, Massachusetts 01886 616 United States 618 Email: erosen@juniper.net 620 Andrew Dolganow 621 Nokia 622 600 March Rd. 623 Ottawa, Ontario K2K 2E6 624 Canada 626 Email: andrew.dolganow@nokia.com 627 Jeff Tantsura 628 Ericsson 629 300 Holger Way 630 San Jose, California 95134 631 United States 633 Email: jeff.tantsura@ericsson.com 635 Sam K Aldrin 636 Google, Inc. 637 1600 Amphitheatre Parkway 638 Mountain View, California 639 United States 641 Email: aldrin.ietf@gmail.com 643 Israel Meilik 644 Broadcom 646 Email: israel@broadcom.com