idnits 2.17.1 draft-ietf-bier-mpls-encapsulation-01.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 (June 5, 2015) is 3247 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 363 -- Looks like a reference, but probably isn't: '65535' on line 363 -- 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-00 == Outdated reference: A later version (-06) exists of draft-chen-ippm-coloring-based-ipfpm-framework-03 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: December 7, 2015 Juniper Networks, Inc. 6 A. Dolganow 7 Alcatel-Lucent 8 J. Tantsura 9 Ericsson 10 S. Aldrin 11 Google, Inc. 12 June 5, 2015 14 Encapsulation for Bit Index Explicit Replication in MPLS Networks 15 draft-ietf-bier-mpls-encapsulation-01 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 December 7, 2015. 50 Copyright Notice 52 Copyright (c) 2015 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. (Of course, if the 222 incoming TTL is 1, the packet will not be forwarded at all, but will 223 be discarded as an MPLS packet whose TTL has been exceeded.) 225 3. BIER Header 227 The BIER header is shown in Figure 1. This header appears after the 228 end of the MPLS label stack, immediately after the MPLS-BIER label. 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |0 1 0 1| Ver | Len | Entropy | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | BitString (first 32 bits) ~ 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 ~ ~ 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 ~ BitString (last 32 bits) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |OAM| Reserved | Proto | BFIR-id | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 1: BIER Header 246 First nibble: 248 The first 4 bits of the header are set to 0101; this ensures that 249 the BIER header will not be confused with an IP header or with the 250 header of a pseudowire packet. If a BFR receives a BIER packet 251 with any other value in the first nibble, it SHOULD discard the 252 packet and log an error. 254 Ver: 256 This 4-bit field identifies the version of the BIER header. This 257 document specifies version 0 of the BIER header. If a packet is 258 received by a particular BFR, and that BFR does not support the 259 specified version of the BIER header, the BFR MUST discard the 260 packet and log an error. 262 The value 0xF is reserved for experimental use; that value MUST 263 NOT be assigned by any future IETF document or by IANA. 265 Len: 267 This 4-bit field encodes the length in bits of the BitString. 269 Note: When parsing the BIER header, a BFR MUST infer the length of 270 the BitString from the BIER-MPLS label, not from the value of this 271 field. This field is present only to enable off-line tools (such 272 as LAN analyzers) to parse the BIER header. 274 If k is the length of the BitString, the value of this field is 275 log2(k)-5. However, only certain values are supported: 277 1: 64 bits 278 2: 128 bits 280 3: 256 bits 282 4: 512 bits 284 5: 1024 bits 286 6: 2048 bits 288 7: 4096 bits 290 The value of this field MUST NOT be set to any value other than 291 those listed above. A received packet containing another value in 292 this field SHOULD be discarded, and an error logged. If the value 293 in this field is other than what is expected based on the BIER- 294 MPLS label, the packet SHOULD be discarded and an error logged. 296 Entropy: 298 This 20-bit field specifies an "entropy" value that can be used 299 for load balancing purposes. The BIER forwarding process may do 300 equal cost load balancing, but the load balancing procedure MUST 301 choose the same path for any two packets have the same entropy 302 value. 304 If a BFIR is encapsulating (as the payload) MPLS packets that have 305 entropy labels, the BFIR MUST ensure that if two such packets have 306 the same MPLS entropy label, they also have the same value of the 307 BIER entropy field. 309 BitString: 311 The BitString that, together with the packet's SI, identifies the 312 destination BFERs for this packet. Note that the SI for the 313 packet is inferred from the BIER-MPLS label that precedes the BIER 314 header. 316 OAM: 318 These two bits are used for the passive performance measurement 319 marking method described in [PPM]. 321 Reserved: 323 These 10 bits are currently unused. They SHOULD be set to zero 324 upon transmission, and MUST be ignored upon reception. 326 Proto: 328 This 4-bit "Next Protocol" field identifies the type of the 329 payload. (The "payload" is the packet or frame immediately 330 following the BIER header.) The protocol field may take any of 331 the following values: 333 1: MPLS packet with downstream-assigned label at top of stack. 335 2: MPLS packet with upstream-assigned label at top of stack (see 336 [RFC5331]). If this value of the Proto field is used, the 337 BFR-id of the BFIR must be placed in the BFIR-id field. The 338 BFIR-id provides the "context" in which the upstream-assigned 339 label is interpreted. 341 3: Ethernet frame. 343 4: IPv4 packet. 345 5: OAM packet [BIER-OAM]. 347 6: IPv6 packet. 349 IANA is requested to set up a registry called "BIER Next Protocol 350 Identifiers", with the above values being assigned initially. 351 Values 0 and 15 are reserved. Values 7-14 are available for 352 assignment according to the Standards Action policy ([RFC5226] and 353 [RFC7120]). 355 If a BFER receives a BIER packet, but does not recognize (or does 356 not support) the value of the Next Protocol field, the BFER SHOULD 357 discard the packet and log an error. 359 BFIR-id: 361 By default, this is the BFR-id of the BFIR, in the sub-domain to 362 which the packet has been assigned. The BFR-id is encoded in the 363 16-bit field as an unsigned integer in the range [1,65535]. 365 Certain applications may require that the BFIR-id field contain 366 the BFR-id of a BFR other than the BFIR. However, that usage of 367 the BFIR-id field is outside the scope of the current document. 369 4. Imposing and Processing the BIER Encapsulation 371 When a BFIR receives a multicast packet from outside the BIER domain, 372 the BFIR carries out the following procedure: 374 1. By consulting the "multicast flow overlay" [BIER_ARCH], it 375 determines the value of the "Proto" field. 377 2. By consulting the "multicast flow overlay", it determines the set 378 of BFERs that must receive the packet. 380 3. If more than one sub-domain is supported, the BFIR assigns the 381 packet to a particular sub-domain. Procedures for determining 382 the sub-domain to which a particular packet should be assigned 383 are outside the scope of this document. 385 4. The BFIR looks up the BFR-id, in the given sub-domain, of each of 386 those BFERs. 388 5. The BFIR converts each such BFR-id into (SI, BitString) format, 389 as described in [BIER_ARCH]. 391 6. All such BFR-ids that have the same SI can be encoded into the 392 same BitString. Details of this encoding can be found in 393 [BIER_ARCH]. For each distinct SI that occurs in the list of the 394 packet's destination BFERs: 396 a. The BFIR makes a copy of the multicast data packet, and 397 encapsulates the copy in a BIER header (see Section 3). The 398 BIER header contains the BitString that represents all the 399 destination BFERs whose BFR-ids (in the given sub-domain) 400 correspond to the given SI. It also contains the BFIR's 401 BFIR-id in the sub-domain to which the packet has been 402 assigned. 404 N.B.: For certain applications, it may be necessary for the 405 BFIR-id field to contain the BFR-id of a BFR other than the 406 BFIR that is creating the header. Such uses are outside the 407 scope of this document, but may be discussed in future 408 revisions. 410 b. The BFIR then applies to that copy the forwarding procedure 411 of [BIER_ARCH]. This may result in one or more copies of 412 the packet (possibly with a modified BitString) being 413 transmitted to a neighboring BFR. 415 c. Before transmitting a copy of the packet to a neighboring 416 BFR, the BFIR finds the BIER-MPLS label that was advertised 417 by the neighbor as corresponding to the given SI, sub- 418 domain, and BitStringLength. An MPLS label stack is then 419 preprended to the packet. This label stack [RFC3032] will 420 contain one label, the aforementioned BIER-MPLS label. The 421 "S" bit MUST be set, indicating the end of the MPLS label 422 stack. The TTL field of this label stack entry is set 423 according to policy. The packet may then be transmitted to 424 the neighboring BFR. (This may result in additional MPLS 425 labels being pushed on the stack. For example, if an RSVP- 426 TE tunnel is used to transmit packets to the neighbor, a 427 label representing that tunnel would be pushed onto the 428 stack.) 430 When an intermediate BFR is processing a received MPLS packet, and 431 one of the BFR's own BIER-MPLS labels rises to the top of the label 432 stack, the BFR infers the sub-domain, SI, and BitStringLength from 433 the label. The BFR then follows the forwarding procedures of 434 [BIER_ARCH]. If it forwards a copy of the packet to a neighboring 435 BFR, it first swaps the label at the top of the label stack with the 436 BIER-MPLS label, advertised by that neighbor, that corresponds to the 437 same SI, sub-domain, and BitStringLength. Note that when this swap 438 operation is done, the TTL field of the BIER-MPLS label of the 439 outgoing packet MUST be one less than the "incoming TTL" of the 440 packet, as defined in Section 2. 442 Thus a BIER-encapsulated packet in an MPLS network consists of a 443 packet that has: 445 o An MPLS label stack with a BIER-MPLS label at the bottom of the 446 stack. 448 o A BIER header, as described in Section 3. 450 o The payload. 452 The payload may be an IPv4 packet, an IPv6 packet, an ethernet frame, 453 an MPLS packet, or an OAM packet. If it is an MPLS packet, the BIER 454 header is followed by a second MPLS label stack; this stack is 455 separate from the stack that precedes the BIER header. For an 456 example of an application where it is useful to carry an MPLS packet 457 as the BIER payload, see [BIER_MVPN]. 459 5. IANA Considerations 461 IANA is requested to set up a registry called "BIER Next Protocol 462 Identifiers", with the values indicated in Section 3 being assigned 463 initially. Values 0 and 15 are reserved. Values 7-14 are available 464 for assignment according to the Standards Action policy ([RFC5226], 465 [RFC7120].) 467 6. Security Considerations 469 As this document makes use of MPLS, it inherits any security 470 considerations that apply to the use of the MPLS data plane. 472 As this document makes use of IGP extensions, it inherits any 473 security considerations that apply to the IGP. 475 The security considerations of [BIER_ARCH] also apply. 477 7. Acknowledgements 479 The authors wish to thank Rajiv Asati, John Bettink, Nagendra Kumar, 480 Christian Martin, Neale Ranns, Greg Shepherd, Ramji Vaithianathan, 481 and Jeffrey Zhang for their ideas and contributions to this work. 483 8. Contributor Addresses 485 Below is a list of other contributing authors in alphabetical order: 487 Mach (Guoyi) Chen 488 Huawei 490 Email: mach.chen@huawei.com 492 Arkadiy Gulko 493 Thomson Reuters 494 195 Broadway 495 New York NY 10007 496 United States 498 Email: arkadiy.gulko@thomsonreuters.com 500 Wim Henderickx 501 Alcatel-Lucent 502 Copernicuslaan 50 503 Antwerp 2018 504 Belgium 506 Email: wim.henderickx@alcatel-lucent.com 508 Martin Horneffer 509 Deutsche Telekom 510 Hammer Str. 216-226 511 Muenster 48153 512 Germany 514 Email: Martin.Horneffer@telekom.de 516 Uwe Joorde 517 Deutsche Telekom 518 Hammer Str. 216-226 519 Muenster D-48153 520 Germany 522 Email: Uwe.Joorde@telekom.de 524 Tony Przygienda 525 Ericsson 526 300 Holger Way 527 San Jose, CA 95134 528 United States 530 Email: antoni.przygienda@ericsson.com 532 9. References 534 9.1. Normative References 536 [BIER_ARCH] 537 Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 538 and S. Aldrin, "Multicast using Bit Index Explicit 539 Replication", internet-draft draft-ietf-bier-architecture- 540 00, April 2015. 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, March 1997. 545 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 546 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 547 Encoding", RFC 3032, January 2001. 549 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 550 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 551 May 2008. 553 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 554 Label Assignment and Context-Specific Label Space", RFC 555 5331, August 2008. 557 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 558 Points", BCP 100, RFC 7120, January 2014. 560 9.2. Informative References 562 [BIER-OAM] 563 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 564 and G. Mirsky, "BIER Ping and Trace", internet-draft 565 draft-kumarzheng-bier-ping-00.txt, March 2015. 567 [BIER_MVPN] 568 Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., 569 Dolganow, A., and T. Przygienda, "Multicast VPN Using 570 Bier", internet-draft draft-ietf-bier-mvpn-00, April 2015. 572 [ISIS_BIER_EXTENSIONS] 573 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 574 "BIER Support via ISIS", internet-draft draft-ietf-bier- 575 isis-extensions-00.txt, April 2015. 577 [OSPF_BIER_EXTENSIONS] 578 Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 579 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 580 for Bit Index Explicit Replication", internet-draft draft- 581 ietf-ospf-bier-extensions-00.txt, April 2015. 583 [PPM] Chen, M., Zheng, L., Mirsky, G., and G. Fioccola, "IP Flow 584 Performance Measurement Framework", draft-chen-ippm- 585 coloring-based-ipfpm-framework-03 (work in progress), 586 February 2015. 588 Authors' Addresses 590 IJsbrand Wijnands (editor) 591 Cisco Systems, Inc. 592 De Kleetlaan 6a 593 Diegem 1831 594 Belgium 596 Email: ice@cisco.com 598 Eric C. Rosen (editor) 599 Juniper Networks, Inc. 600 10 Technology Park Drive 601 Westford, Massachusetts 01886 602 United States 604 Email: erosen@juniper.net 606 Andrew Dolganow 607 Alcatel-Lucent 608 600 March Rd. 609 Ottawa, Ontario K2K 2E6 610 Canada 612 Email: andrew.dolganow@alcatel-lucent.com 614 Jeff Tantsura 615 Ericsson 616 300 Holger Way 617 San Jose, California 95134 618 United States 620 Email: jeff.tantsura@ericsson.com 621 Sam K Aldrin 622 Google, Inc. 623 1600 Amphitheatre Parkway 624 Mountain View, California 625 United States 627 Email: aldrin.ietf@gmail.com