idnits 2.17.1 draft-ietf-bier-mpls-encapsulation-04.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 18, 2016) is 2902 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 370 -- Looks like a reference, but probably isn't: '65535' on line 370 -- Looks like a reference, but probably isn't: '512' on line 156 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-03) exists of draft-kumarzheng-bier-ping-02 Summary: 1 error (**), 0 flaws (~~), 2 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: October 20, 2016 Juniper Networks, Inc. 6 A. Dolganow 7 Nokia 8 J. Tantsura 9 Ericsson 10 S. Aldrin 11 Google, Inc. 12 April 18, 2016 14 Encapsulation for Bit Index Explicit Replication in MPLS Networks 15 draft-ietf-bier-mpls-encapsulation-04 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 October 20, 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. 152 Penultimate hop popping MUST NOT be applied to a BIER-MPLS label. 154 Suppose for example that there is a single sub-domain (the default 155 sub-domain), that the network is using a BitStringLength of 256, and 156 that all BFERs in the sub-domain have BFR-ids in the range [1,512]. 157 Since each BIER BitString is 256 bits long, this requires the use of 158 two SIs: SI=0 and SI=1. So each BFR will advertise, via IGP 159 extensions, two MPLS labels for BIER: one corresponding to SI=0 and 160 one corresponding to SI=1. The advertisements of these labels will 161 also bind each label to the default sub-domain and to the 162 BitStringLength 256. 164 As another example, suppose a particular BIER domain contains 2 sub- 165 domains (sub-domain 0 and sub-domain 1), supports 2 BitStringLengths 166 (256 and 512), and contains 1024 BFRs. A BFR that is provisioned for 167 both sub-domains, and that supports both BitStringLengths, would have 168 to advertise the following set of BIER-MPLS labels: 170 L1: corresponding to sub-domain 0, BitStringLength 256, SI 0. 172 L2: corresponding to sub-domain 0, BitStringLength 256, SI 1. 174 L3: corresponding to sub-domain 0, BitStringLength 256, SI 2. 176 L4: corresponding to sub-domain 0, BitStringLength 256, SI 3. 178 L5: corresponding to sub-domain 0, BitStringLength 512, SI 0. 180 L6: corresponding to sub-domain 0, BitStringLength 512, SI 1. 182 L7: corresponding to sub-domain 1, BitStringLength 256, SI 0. 184 L8: corresponding to sub-domain 1, BitStringLength 256, SI 1. 186 L9: corresponding to sub-domain 1, BitStringLength 256, SI 2. 188 L10: corresponding to sub-domain 1, BitStringLength 256, SI 3. 190 L11: corresponding to sub-domain 1, BitStringLength 512, SI 0. 192 L12: corresponding to sub-domain 1, BitStringLength 512, SI 1. 194 The above example should not be taken as implying that the BFRs need 195 to advertise 12 individual labels. For instance, instead of 196 advertising a label for and 197 a label for , a BFR could 198 advertise a contiguous range of labels (in this case, a range 199 containing exactly two labels) corresponding to . The first label in the range could correspond 201 to SI 0, and the second to SI 1. The precise mechanism for 202 generating and forming the advertisements is outside the scope of 203 this document. See [OSPF_BIER_EXTENSIONS] and 204 [ISIS_BIER_EXTENSIONS]. 206 Note that, in practice, labels only have to be assigned if they are 207 going to be used. If a particular BIER domain supports 208 BitStringLengths 256 and 512, but some sub-domain, say sub-domain 1, 209 only uses BitStringLength 256, then it is not necessary to assign 210 labels that correspond to the combination of sub-domain 1 and 211 BitStringLength 512. 213 When a BFR receives an MPLS packet, and the next label to be 214 processed is one of its BIER-MPLS labels, it will assume that a BIER 215 header (see Section 3) immediately follows the stack. It will also 216 infer the packet's sub-domain, SI, and BitStringLength from the 217 label. The packet's "incoming TTL" (see below) is taken from the TTL 218 field of the label stack entry that contains the BIER-MPLS label. 220 The BFR MUST perform the MPLS TTL processing correctly. If the 221 packet is forwarded to one or more BFR adjacencies, the BIER-MPLS 222 label carried by the forwarded packet MUST have a TTL field whose 223 value is one less than that of the incoming TTL. 225 Of course, if the incoming TTL is 1, the packet MUST be treated as a 226 packet whose TTL has been exceeded. The packet MUST NOT be 227 forwarded, but it MAY be passed to other layers for processing (e.g., 228 to cause an ICMP message to be generated, and/or to invoke BIER- 229 specific traceroute procedures, and/or to invoke other OAM 230 procedures.) 232 3. BIER Header 234 The BIER header is shown in Figure 1. This header appears after the 235 end of the MPLS label stack, immediately after the MPLS-BIER label. 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 |0 1 0 1| Ver | Len | Entropy | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | BitString (first 32 bits) ~ 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 ~ ~ 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 ~ BitString (last 32 bits) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |OAM| Reserved | Proto | BFIR-id | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 1: BIER Header 253 First nibble: 255 The first 4 bits of the header are set to 0101; this ensures that 256 the BIER header will not be confused with an IP header or with the 257 header of a pseudowire packet. If a BFR receives a BIER packet 258 with any other value in the first nibble, it SHOULD discard the 259 packet and log an error. 261 Ver: 263 This 4-bit field identifies the version of the BIER header. This 264 document specifies version 0 of the BIER header. If a packet is 265 received by a particular BFR, and that BFR does not support the 266 specified version of the BIER header, the BFR MUST discard the 267 packet and log an error. 269 The value 0xF is reserved for experimental use; that value MUST 270 NOT be assigned by any future IETF document or by IANA. 272 Len: 274 This 4-bit field encodes the length in bits of the BitString. 276 Note: When parsing the BIER header, a BFR MUST infer the length of 277 the BitString from the BIER-MPLS label, not from the value of this 278 field. This field is present only to enable off-line tools (such 279 as LAN analyzers) to parse the BIER header. 281 If k is the length of the BitString, the value of this field is 282 log2(k)-5. However, only certain values are supported: 284 1: 64 bits 285 2: 128 bits 287 3: 256 bits 289 4: 512 bits 291 5: 1024 bits 293 6: 2048 bits 295 7: 4096 bits 297 The value of this field MUST NOT be set to any value other than 298 those listed above. A received packet containing another value in 299 this field SHOULD be discarded, and an error logged. If the value 300 in this field is other than what is expected based on the BIER- 301 MPLS label, the packet SHOULD be discarded and an error logged. 303 Entropy: 305 This 20-bit field specifies an "entropy" value that can be used 306 for load balancing purposes. The BIER forwarding process may do 307 equal cost load balancing, but the load balancing procedure MUST 308 choose the same path for any two packets have the same entropy 309 value. 311 If a BFIR is encapsulating (as the payload) MPLS packets that have 312 entropy labels, the BFIR MUST ensure that if two such packets have 313 the same MPLS entropy label, they also have the same value of the 314 BIER entropy field. 316 BitString: 318 The BitString that, together with the packet's SI, identifies the 319 destination BFERs for this packet. Note that the SI for the 320 packet is inferred from the BIER-MPLS label that precedes the BIER 321 header. 323 OAM: 325 These two bits are used for the passive performance measurement 326 marking method described in [PPM]. 328 Reserved: 330 These 10 bits are currently unused. They SHOULD be set to zero 331 upon transmission, and MUST be ignored upon reception. 333 Proto: 335 This 4-bit "Next Protocol" field identifies the type of the 336 payload. (The "payload" is the packet or frame immediately 337 following the BIER header.) The protocol field may take any of 338 the following values: 340 1: MPLS packet with downstream-assigned label at top of stack. 342 2: MPLS packet with upstream-assigned label at top of stack (see 343 [RFC5331]). If this value of the Proto field is used, the 344 BFR-id of the BFIR must be placed in the BFIR-id field. The 345 BFIR-id provides the "context" in which the upstream-assigned 346 label is interpreted. 348 3: Ethernet frame. 350 4: IPv4 packet. 352 5: OAM packet [BIER-OAM]. 354 6: IPv6 packet. 356 IANA is requested to set up a registry called "BIER Next Protocol 357 Identifiers", with the above values being assigned initially. 358 Values 0 and 15 are reserved. Values 7-14 are available for 359 assignment according to the Standards Action policy ([RFC5226] and 360 [RFC7120]). 362 If a BFER receives a BIER packet, but does not recognize (or does 363 not support) the value of the Next Protocol field, the BFER SHOULD 364 discard the packet and log an error. 366 BFIR-id: 368 By default, this is the BFR-id of the BFIR, in the sub-domain to 369 which the packet has been assigned. The BFR-id is encoded in the 370 16-bit field as an unsigned integer in the range [1,65535]. 372 Certain applications may require that the BFIR-id field contain 373 the BFR-id of a BFR other than the BFIR. However, that usage of 374 the BFIR-id field is outside the scope of the current document. 376 4. Imposing and Processing the BIER Encapsulation 378 When a BFIR receives a multicast packet from outside the BIER domain, 379 the BFIR carries out the following procedure: 381 1. By consulting the "multicast flow overlay" [BIER_ARCH], it 382 determines the value of the "Proto" field. 384 2. By consulting the "multicast flow overlay", it determines the set 385 of BFERs that must receive the packet. 387 3. If more than one sub-domain is supported, the BFIR assigns the 388 packet to a particular sub-domain. Procedures for determining 389 the sub-domain to which a particular packet should be assigned 390 are outside the scope of this document. 392 4. The BFIR looks up the BFR-id, in the given sub-domain, of each of 393 those BFERs. 395 5. The BFIR converts each such BFR-id into (SI, BitString) format, 396 as described in [BIER_ARCH]. 398 6. All such BFR-ids that have the same SI can be encoded into the 399 same BitString. Details of this encoding can be found in 400 [BIER_ARCH]. For each distinct SI that occurs in the list of the 401 packet's destination BFERs: 403 a. The BFIR makes a copy of the multicast data packet, and 404 encapsulates the copy in a BIER header (see Section 3). The 405 BIER header contains the BitString that represents all the 406 destination BFERs whose BFR-ids (in the given sub-domain) 407 correspond to the given SI. It also contains the BFIR's 408 BFIR-id in the sub-domain to which the packet has been 409 assigned. 411 N.B.: For certain applications, it may be necessary for the 412 BFIR-id field to contain the BFR-id of a BFR other than the 413 BFIR that is creating the header. Such uses are outside the 414 scope of this document, but may be discussed in future 415 revisions. 417 b. The BFIR then applies to that copy the forwarding procedure 418 of [BIER_ARCH]. This may result in one or more copies of 419 the packet (possibly with a modified BitString) being 420 transmitted to a neighboring BFR. 422 c. Before transmitting a copy of the packet to a neighboring 423 BFR, the BFIR finds the BIER-MPLS label that was advertised 424 by the neighbor as corresponding to the given SI, sub- 425 domain, and BitStringLength. An MPLS label stack is then 426 preprended to the packet. This label stack [RFC3032] will 427 contain one label, the aforementioned BIER-MPLS label. The 428 "S" bit MUST be set, indicating the end of the MPLS label 429 stack. The TTL field of this label stack entry is set 430 according to policy. The packet may then be transmitted to 431 the neighboring BFR. (This may result in additional MPLS 432 labels being pushed on the stack. For example, if an RSVP- 433 TE tunnel is used to transmit packets to the neighbor, a 434 label representing that tunnel would be pushed onto the 435 stack.) 437 When an intermediate BFR is processing a received MPLS packet, and 438 one of the BFR's own BIER-MPLS labels rises to the top of the label 439 stack, the BFR infers the sub-domain, SI, and BitStringLength from 440 the label. The BFR then follows the forwarding procedures of 441 [BIER_ARCH]. If it forwards a copy of the packet to a neighboring 442 BFR, it first swaps the label at the top of the label stack with the 443 BIER-MPLS label, advertised by that neighbor, that corresponds to the 444 same SI, sub-domain, and BitStringLength. Note that when this swap 445 operation is done, the TTL field of the BIER-MPLS label of the 446 outgoing packet MUST be one less than the "incoming TTL" of the 447 packet, as defined in Section 2. 449 Thus a BIER-encapsulated packet in an MPLS network consists of a 450 packet that has: 452 o An MPLS label stack with a BIER-MPLS label at the bottom of the 453 stack. 455 o A BIER header, as described in Section 3. 457 o The payload. 459 The payload may be an IPv4 packet, an IPv6 packet, an ethernet frame, 460 an MPLS packet, or an OAM packet. If it is an MPLS packet, the BIER 461 header is followed by a second MPLS label stack; this stack is 462 separate from the stack that precedes the BIER header. For an 463 example of an application where it is useful to carry an MPLS packet 464 as the BIER payload, see [BIER_MVPN]. 466 5. IANA Considerations 468 IANA is requested to set up a registry called "BIER Next Protocol 469 Identifiers", with the values indicated in Section 3 being assigned 470 initially. Values 0 and 15 are reserved. Values 7-14 are available 471 for assignment according to the Standards Action policy ([RFC5226], 472 [RFC7120].) 474 6. Security Considerations 476 As this document makes use of MPLS, it inherits any security 477 considerations that apply to the use of the MPLS data plane. 479 As this document makes use of IGP extensions, it inherits any 480 security considerations that apply to the IGP. 482 The security considerations of [BIER_ARCH] also apply. 484 7. Acknowledgements 486 The authors wish to thank Rajiv Asati, John Bettink, Nagendra Kumar, 487 Christian Martin, Neale Ranns, Greg Shepherd, Ramji Vaithianathan, 488 and Jeffrey Zhang for their ideas and contributions to this work. 490 8. Contributor Addresses 492 Below is a list of other contributing authors in alphabetical order: 494 Mach (Guoyi) Chen 495 Huawei 497 Email: mach.chen@huawei.com 499 Arkadiy Gulko 500 Thomson Reuters 501 195 Broadway 502 New York NY 10007 503 United States 505 Email: arkadiy.gulko@thomsonreuters.com 507 Wim Henderickx 508 Nokia 509 Copernicuslaan 50 510 Antwerp 2018 511 Belgium 513 Email: wim.henderickx@nokia.com 515 Martin Horneffer 516 Deutsche Telekom 517 Hammer Str. 216-226 518 Muenster 48153 519 Germany 521 Email: Martin.Horneffer@telekom.de 523 Uwe Joorde 524 Deutsche Telekom 525 Hammer Str. 216-226 526 Muenster D-48153 527 Germany 529 Email: Uwe.Joorde@telekom.de 531 Tony Przygienda 532 Juniper Networks, Inc. 533 1194 N. Mathilda Ave. 534 Sunnyvale, California 94089 535 United States 537 Email: prz@juniper.net 539 9. References 541 9.1. Normative References 543 [BIER_ARCH] 544 Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 545 and S. Aldrin, "Multicast using Bit Index Explicit 546 Replication", internet-draft draft-ietf-bier-architecture- 547 03, January 2016. 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, 551 DOI 10.17487/RFC2119, March 1997, 552 . 554 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 555 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 556 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 557 . 559 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 560 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 561 DOI 10.17487/RFC5226, May 2008, 562 . 564 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 565 Label Assignment and Context-Specific Label Space", 566 RFC 5331, DOI 10.17487/RFC5331, August 2008, 567 . 569 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 570 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 571 2014, . 573 9.2. Informative References 575 [BIER-OAM] 576 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 577 and G. Mirsky, "BIER Ping and Trace", internet-draft 578 draft-kumarzheng-bier-ping-02.txt, December 2015. 580 [BIER_MVPN] 581 Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 582 Dolganow, A., and T. Przygienda, "Multicast VPN Using 583 Bier", internet-draft draft-ietf-bier-mvpn-02, December 584 2015. 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-01.txt, October 2015. 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