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