draft-ietf-bier-architecture-03.txt   draft-ietf-bier-architecture-04.txt 
Internet Engineering Task Force IJ. Wijnands, Ed. Internet Engineering Task Force IJ. Wijnands, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track E. Rosen, Ed. Intended status: Standards Track E. Rosen, Ed.
Expires: July 22, 2016 Juniper Networks, Inc. Expires: January 19, 2017 Juniper Networks, Inc.
A. Dolganow A. Dolganow
Alcatel-Lucent Nokia
T. Przygienda T. Przygienda
Ericsson Juniper Networks, Inc.
S. Aldrin S. Aldrin
Google, Inc. Google, Inc.
January 19, 2016 July 18, 2016
Multicast using Bit Index Explicit Replication Multicast using Bit Index Explicit Replication
draft-ietf-bier-architecture-03 draft-ietf-bier-architecture-04
Abstract Abstract
This document specifies a new architecture for the forwarding of This document specifies a new architecture for the forwarding of
multicast data packets. It provides optimal forwarding of multicast multicast data packets. It provides optimal forwarding of multicast
packets through a "multicast domain". However, it does not require a packets through a "multicast domain". However, it does not require a
protocol for explicitly building multicast distribution trees, nor protocol for explicitly building multicast distribution trees, nor
does it require intermediate nodes to maintain any per-flow state. does it require intermediate nodes to maintain any per-flow state.
This architecture is known as "Bit Index Explicit Replication" This architecture is known as "Bit Index Explicit Replication"
(BIER). When a multicast data packet enters the domain, the ingress (BIER). When a multicast data packet enters the domain, the ingress
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 22, 2016. This Internet-Draft will expire on January 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
4. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. The Routing Underlay . . . . . . . . . . . . . . . . . . 9 4.1. The Routing Underlay . . . . . . . . . . . . . . . . . . 9
4.2. The BIER Layer . . . . . . . . . . . . . . . . . . . . . 10 4.2. The BIER Layer . . . . . . . . . . . . . . . . . . . . . 10
4.3. The Multicast Flow Overlay . . . . . . . . . . . . . . . 11 4.3. The Multicast Flow Overlay . . . . . . . . . . . . . . . 11
5. Advertising BFR-ids and BFR-Prefixes . . . . . . . . . . . . 11 5. Advertising BFR-ids and BFR-Prefixes . . . . . . . . . . . . 11
6. BIER Intra-Domain Forwarding Procedures . . . . . . . . . . . 13 6. BIER Intra-Domain Forwarding Procedures . . . . . . . . . . . 13
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. BFR Neighbors . . . . . . . . . . . . . . . . . . . . . . 14 6.2. BFR Neighbors . . . . . . . . . . . . . . . . . . . . . . 14
6.3. The Bit Index Routing Table . . . . . . . . . . . . . . . 15 6.3. The Bit Index Routing Table . . . . . . . . . . . . . . . 15
6.4. The Bit Index Forwarding Table . . . . . . . . . . . . . 16 6.4. The Bit Index Forwarding Table . . . . . . . . . . . . . 16
6.5. The BIER Forwarding Procedure . . . . . . . . . . . . . . 16 6.5. The BIER Forwarding Procedure . . . . . . . . . . . . . . 17
6.6. Examples of BIER Forwarding . . . . . . . . . . . . . . . 18 6.6. Examples of BIER Forwarding . . . . . . . . . . . . . . . 19
6.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 19 6.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 20
6.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 20 6.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 21
6.7. Equal Cost Multi-path Forwarding . . . . . . . . . . . . 22 6.7. Equal Cost Multi-path Forwarding . . . . . . . . . . . . 23
6.7.1. Non-deterministic ECMP . . . . . . . . . . . . . . . 22 6.7.1. Non-deterministic ECMP . . . . . . . . . . . . . . . 23
6.7.2. Deterministic ECMP . . . . . . . . . . . . . . . . . 23 6.7.2. Deterministic ECMP . . . . . . . . . . . . . . . . . 24
6.8. Prevention of Loops and Duplicates . . . . . . . . . . . 25 6.8. Prevention of Loops and Duplicates . . . . . . . . . . . 26
6.9. When Some Nodes do not Support BIER . . . . . . . . . . . 26 6.9. When Some Nodes do not Support BIER . . . . . . . . . . . 27
6.10. Use of Different BitStringLengths within a Domain . . . . 28 6.10. Use of Different BitStringLengths within a Domain . . . . 29
6.10.1. BitStringLength Compatibility Check . . . . . . . . 29 6.10.1. BitStringLength Compatibility Check . . . . . . . . 30
6.10.2. Handling BitStringLength Mismatches . . . . . . . . 31 6.10.2. Handling BitStringLength Mismatches . . . . . . . . 32
6.10.3. Transitioning from One BitStringLength to Another . 31 6.10.3. Transitioning from One BitStringLength to Another . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 32 10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.1. Normative References . . . . . . . . . . . . . . . . . . 34 11.1. Normative References . . . . . . . . . . . . . . . . . . 35
11.2. Informative References . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
This document specifies a new architecture for the forwarding of This document specifies a new architecture for the forwarding of
multicast data packets. It provides optimal forwarding of multicast multicast data packets. It provides optimal forwarding of multicast
data packets through a "multicast domain". However, it does not data packets through a "multicast domain". However, it does not
require the use of a protocol for explicitly building multicast require the use of a protocol for explicitly building multicast
distribution trees, and it does not require intermediate nodes to distribution trees, and it does not require intermediate nodes to
maintain any per-flow state. This architecture is known as "Bit maintain any per-flow state. This architecture is known as "Bit
Index Explicit Replication" (BIER). Index Explicit Replication" (BIER).
skipping to change at page 6, line 31 skipping to change at page 6, line 31
BFR-prefix be a loopback address of the BFR. Two BFRs in the same BFR-prefix be a loopback address of the BFR. Two BFRs in the same
BIER domain MUST NOT be assigned the same BFR-Prefix. Note that a BIER domain MUST NOT be assigned the same BFR-Prefix. Note that a
BFR in a given BIER domain has the same BFR-prefix in all the sub- BFR in a given BIER domain has the same BFR-prefix in all the sub-
domains of that BIER domain. domains of that BIER domain.
A "BFR Identifier" (BFR-id) is a number in the range [1,65535]. In A "BFR Identifier" (BFR-id) is a number in the range [1,65535]. In
general, each BFR in a given BIER sub-domain must be assigned a general, each BFR in a given BIER sub-domain must be assigned a
unique number from this range (i.e., two BFRs in the same BIER sub- unique number from this range (i.e., two BFRs in the same BIER sub-
domain MUST NOT have the same BFR-id in that sub-domain). However, domain MUST NOT have the same BFR-id in that sub-domain). However,
if it is known that a given BFR will never need to function as a BFER if it is known that a given BFR will never need to function as a BFER
in a given sub-domain, then it is not necessary to assign a BFR-id or BFIR in a given sub-domain, then it is not necessary to assign a
for that sub-domain to that BFR. BFR-id for that sub-domain to that BFR.
Note that the value 0 is not a legal BFR-id. Note that the value 0 is not a legal BFR-id.
The procedure for assigning a particular BFR-id to a particular BFR The procedure for assigning a particular BFR-id to a particular BFR
is outside the scope of this document. However, it is RECOMMENDED is outside the scope of this document. However, it is RECOMMENDED
that the BFR-ids for each sub-domain be assigned "densely" from the that the BFR-ids for each sub-domain be assigned "densely" from the
numbering space, as this will result in a more efficient encoding numbering space, as this will result in a more efficient encoding
(see Section 3). That is, if there are 256 or fewer BFERs, it is (see Section 3). That is, if there are 256 or fewer BFERs, it is
RECOMMENDED to assign all the BFR-ids from the range [1,256]. If RECOMMENDED to assign all the BFR-ids from the range [1,256]. If
there are more than 256 BFERs, but less than 512, it is RECOMMENDED there are more than 256 BFERs, but less than 512, it is RECOMMENDED
skipping to change at page 7, line 19 skipping to change at page 7, line 19
o The BitString has one bit position set. If the low-order bit is o The BitString has one bit position set. If the low-order bit is
bit 1, and the high-order bit is bit BitStringLength, the bit bit 1, and the high-order bit is bit BitStringLength, the bit
position that represents BFR-id N is position that represents BFR-id N is
((N-1) modulo BitStringLength)+1. ((N-1) modulo BitStringLength)+1.
If several different BFR-ids all resolve to the same SI, then all If several different BFR-ids all resolve to the same SI, then all
those BFR-ids can be represented in a single BitString. The those BFR-ids can be represented in a single BitString. The
BitStrings for all of those BFR-ids are combined using a bitwise BitStrings for all of those BFR-ids are combined using a bitwise
logical OR operation. logical OR operation.
Different BIER domains may use different values of BitStringLength. Within a given BIER domain (or even within a given BIER sub-domain),
Each BFR in a given BIER domain MUST be provisioned to know the different values of BitStringLength may be used. Each BFR MUST be
following: provisioned to know the following:
o the BitStringLength ("Imposition BitStringLength") and sub-domain o the BitStringLength ("Imposition BitStringLength") and sub-domain
("Imposition sub-domain") to use when it imposes (as a BFIR) a ("Imposition sub-domain") to use when it imposes (as a BFIR) a
BIER encapsulation on a particular set of packets, and BIER encapsulation on a particular set of packets, and
o the BitStringLengths ("Disposition BitStringLengths") that it will o the BitStringLengths ("Disposition BitStringLengths") that it will
process when (as a BFR or BFER) it receives packets from a process when (as a BFR or BFER) it receives packets from a
particular sub-domain. particular sub-domain.
It is not required that a BFIR use the same Imposition It is not required that a BFIR use the same Imposition
skipping to change at page 13, line 13 skipping to change at page 13, line 13
new BFR from impacting an existing BFR. new BFR from impacting an existing BFR.
If a BFR advertises that it has a BFR-id of 0 in a particular sub- If a BFR advertises that it has a BFR-id of 0 in a particular sub-
domain, other BFRs receiving the advertisement MUST interpret that domain, other BFRs receiving the advertisement MUST interpret that
advertisement as meaning that the advertising BFR does not have a advertisement as meaning that the advertising BFR does not have a
BFR-id in that sub-domain. BFR-id in that sub-domain.
6. BIER Intra-Domain Forwarding Procedures 6. BIER Intra-Domain Forwarding Procedures
This section specifies the rules for forwarding a BIER-encapsulated This section specifies the rules for forwarding a BIER-encapsulated
data packet within a BIER domain. data packet within a BIER domain. These rules are not intended to
specify an implementation strategy; to conform to this specification,
an implementation need only produce the same results that these rules
produce.
6.1. Overview 6.1. Overview
This section provides a brief overview of the BIER forwarding This section provides a brief overview of the BIER forwarding
procedures. Subsequent sub-sections specify the procedures in more procedures. Subsequent sub-sections specify the procedures in more
detail. detail.
To forward a BIER-encapsulated packet: To forward a BIER-encapsulated packet:
1. Determine the packet's sub-domain. 1. Determine the packet's sub-domain.
skipping to change at page 13, line 36 skipping to change at page 13, line 39
3. Determine the packet's SI. 3. Determine the packet's SI.
4. From the sub-domain, the SI and the BitString, determine the set 4. From the sub-domain, the SI and the BitString, determine the set
of destination BFERs for the packet. of destination BFERs for the packet.
5. Using information provided by the routing underlay associated 5. Using information provided by the routing underlay associated
with the packet's sub-domain, determine the next hop adjacency with the packet's sub-domain, determine the next hop adjacency
for each of the destination BFERs. for each of the destination BFERs.
6. Partition the set of destination BFERs such that all the BFERs in 6. It is possible that the packet's BitString will have one or more
bits that correspond to BFR-ids that are not in use. It is also
possible that the packet's BitString will have one or more bits
that correspond to BFERs that are unreachable, i.e., that have no
next hop adjacency. In the following, we will consider the "next
hop adjacency" for all such bit positions to be the "null" next
hop.
7. Partition the set of destination BFERs such that all the BFERs in
a single partition have the same next hop. We will say that each a single partition have the same next hop. We will say that each
partition is associated with a next hop. partition is associated with a next hop.
7. For each partition: 8. For each partition:
a. Make a copy of the packet. a. Make a copy of the packet.
b. Clear any bit in the packet's BitString that identifies a b. Clear any bit in the packet's BitString that identifies a
BFER that is not in the partition. BFER that is not in the partition.
c. Transmit the packet to the associated next hop. c. Transmit the packet to the associated next hop. (If the next
hop is the null next hop, the packet is discarded.)
If a BFR receives a BIER-encapsulated packet whose sub-domain, SI and If a BFR receives a BIER-encapsulated packet whose sub-domain, SI and
BitString identify that BFR itself, then the BFR is also a BFER for BitString identify that BFR itself, then the BFR is also a BFER for
that packet. As a BFER, it must pass the payload to the multicast that packet. As a BFER, it must pass the payload to the multicast
flow overlay. If the BitString has bits set for other BFRs, the flow overlay. If the BitString has bits set for other BFRs, the
packet also needs to be forwarded further within the BIER domain. If packet also needs to be forwarded further within the BIER domain. If
the BF(E)R also forwards one or more copies of the packet within the the BF(E)R also forwards one or more copies of the packet within the
BIER domain, the bit representing the BFR's own BFR-id MUST be clear BIER domain, the bit representing the BFR's own BFR-id MUST be clear
in all the copies. in all the copies.
skipping to change at page 17, line 25 skipping to change at page 17, line 51
copy to the multicast flow overlay. Then clear bit k in the copy to the multicast flow overlay. Then clear bit k in the
original packet, and go to step 2. Otherwise, proceed to step 5. original packet, and go to step 2. Otherwise, proceed to step 5.
5. Use the value k, together with the SI, sub-domain, and 5. Use the value k, together with the SI, sub-domain, and
BitStringLength, as the 'index' into the BIFT. BitStringLength, as the 'index' into the BIFT.
6. Extract from the BIFT the F-BM and the BFR-NBR. 6. Extract from the BIFT the F-BM and the BFR-NBR.
7. Copy the packet. Update the copy's BitString by AND'ing it with 7. Copy the packet. Update the copy's BitString by AND'ing it with
the F-BM (i.e., PacketCopy->BitString &= F-BM). Then forward the the F-BM (i.e., PacketCopy->BitString &= F-BM). Then forward the
copy to the BFR-NBR. Note that when a packet is forwarded to a copy to the BFR-NBR. (If the BFR-NBR is null, the copy is just
particular BFR-NBR, its BitString identifies only those BFERs discarded.) Note that when a packet is forwarded to a particular
that are to be reached via that BFR-NBR. BFR-NBR, its BitString identifies only those BFERs that are to be
reached via that BFR-NBR.
8. Now update the original packet's BitString by AND'ing it with the 8. Now update the original packet's BitString by AND'ing it with the
INVERSE of the F-BM (i.e., Packet->Bitstring &= ~F-BM). (This INVERSE of the F-BM (i.e., Packet->Bitstring &= ~F-BM). (This
clears the bits that identify the BFERs to which a copy of the clears the bits that identify the BFERs to which a copy of the
packet has just been forwarded.) Go to step 2. packet has just been forwarded.) Go to step 2.
Note that this procedure causes the packet to be forwarded to a Note that this procedure causes the packet to be forwarded to a
particular BFR-NBR only once. The number of lookups in the BIFT is particular BFR-NBR only once. The number of lookups in the BIFT is
the same as the number of BFR-NBRs to which the packet must be the same as the number of BFR-NBRs to which the packet must be
forwarded; it is not necessary to do a separate lookup for each forwarded; it is not necessary to do a separate lookup for each
skipping to change at page 18, line 43 skipping to change at page 19, line 29
} }
Figure 4: Pseudocode Figure 4: Pseudocode
This pseudocode assumes that at a given BFER, the BFR-NBR entry This pseudocode assumes that at a given BFER, the BFR-NBR entry
corresponding to the BFER's own BFR-id will be the BFER's own corresponding to the BFER's own BFR-id will be the BFER's own
BFR-prefix. It also assumes that the corresponding F-BM has only one BFR-prefix. It also assumes that the corresponding F-BM has only one
bit set, the bit representing the BFER itself. In this case, the bit set, the bit representing the BFER itself. In this case, the
"PacketSend" function sends the packet to the multicast flow overlay. "PacketSend" function sends the packet to the multicast flow overlay.
This pseudocode also assumes that the F-BM for the null next hop
contains a 1 in a given bit position if and only if that bit position
corresponds either to an unused BFR-id or to an unreachable BFER.
When the BFR-NBR is null, the "PacketSend" function discards the
packet.
6.6. Examples of BIER Forwarding 6.6. Examples of BIER Forwarding
In this section, we give two examples of BIER forwarding, based on In this section, we give two examples of BIER forwarding, based on
the topology in Figure 1. In these examples, all packets have been the topology in Figure 1. In these examples, all packets have been
assigned to the default sub-domain, all packets have SI=0, and the assigned to the default sub-domain, all packets have SI=0, and the
BitStringLength is 4. Figure 5 shows the BIFT entries for SI=0 only. BitStringLength is 4. Figure 5 shows the BIFT entries for SI=0 only.
For compactness, we show the first column of the BIFT, the BFR-id, For compactness, we show the first column of the BIFT, the BFR-id,
only as an integer. only as an integer.
BFR-A BIFT BFR-B BIFT BFR-C BIFT BFR-A BIFT BFR-B BIFT BFR-C BIFT
skipping to change at page 33, line 15 skipping to change at page 34, line 15
Arkadiy Gulko Arkadiy Gulko
Thomson Reuters Thomson Reuters
195 Broadway 195 Broadway
New York NY 10007 New York NY 10007
United States United States
Email: arkadiy.gulko@thomsonreuters.com Email: arkadiy.gulko@thomsonreuters.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Nokia
Copernicuslaan 50 Copernicuslaan 50
Antwerp 2018 Antwerp 2018
Belgium Belgium
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@nokia.com
Martin Horneffer Martin Horneffer
Deutsche Telekom Deutsche Telekom
Hammer Str. 216-226 Hammer Str. 216-226
Muenster 48153 Muenster 48153
Germany Germany
Email: Martin.Horneffer@telekom.de Email: Martin.Horneffer@telekom.de
Uwe Joorde Uwe Joorde
skipping to change at page 33, line 47 skipping to change at page 34, line 47
Luay Jalil Luay Jalil
Verizon Verizon
1201 E Arapaho Rd. 1201 E Arapaho Rd.
Richardson, TX 75081 Richardson, TX 75081
United States United States
Email: luay.jalil@verizon.com Email: luay.jalil@verizon.com
Jeff Tantsura Jeff Tantsura
Ericsson
300 Holger Way
San Jose, CA 95134
United States
Email: jeff.tantsura@ericsson.com Email: jefftant.ietf@gmail.com
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 34, line 31 skipping to change at page 35, line 28
11.2. Informative References 11.2. Informative References
[Boivie_Feldman] [Boivie_Feldman]
Boivie, R. and N. Feldman, "Small Group Multicast", Boivie, R. and N. Feldman, "Small Group Multicast",
(expired) draft-boivie-sgm-02.txt, February 2001. (expired) draft-boivie-sgm-02.txt, February 2001.
[ISIS_BIER_EXTENSIONS] [ISIS_BIER_EXTENSIONS]
Ginsberg, L., Przygienda, T., Aldrin, S., and J. Zhang, Ginsberg, L., Przygienda, T., Aldrin, S., and J. Zhang,
"BIER Support via ISIS", internet-draft draft-ietf-bier- "BIER Support via ISIS", internet-draft draft-ietf-bier-
isis-extensions-01.txt, October 2015. isis-extensions-02.txt, March 2016.
[MPLS_BIER_ENCAPS] [MPLS_BIER_ENCAPS]
Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., and Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J.,
S. Aldrin, "Encapsulation for Bit Index Explicit Aldrin, S., and I. Meilik, "Encapsulation for Bit Index
Replication in MPLS Networks", internet-draft draft-ietf- Explicit Replication in MPLS Networks", internet-draft
bier-mpls-encapsulation-02.txt, August 2015. draft-ietf-bier-mpls-encapsulation-05.txt, July 2016.
[OSPF_BIER_EXTENSIONS] [OSPF_BIER_EXTENSIONS]
Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A.,
Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions
for Bit Index Explicit Replication", internet-draft draft- for Bit Index Explicit Replication", internet-draft draft-
ietf-ospf-bier-extensions-01.txt, October 2015. ietf-ospf-bier-extensions-02.txt, March 2016.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>. 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>. <http://www.rfc-editor.org/info/rfc6514>.
skipping to change at page 35, line 29 skipping to change at page 36, line 24
Eric C. Rosen (editor) Eric C. Rosen (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
United States United States
Email: erosen@juniper.net Email: erosen@juniper.net
Andrew Dolganow Andrew Dolganow
Alcatel-Lucent Nokia
600 March Rd. 600 March Rd.
Ottawa, Ontario K2K 2E6 Ottawa, Ontario K2K 2E6
Canada Canada
Email: andrew.dolganow@alcatel-lucent.com Email: andrew.dolganow@nokia.com
Tony Przygienda Tony Przygienda
Ericsson Juniper Networks, Inc.
300 Holger Way 1194 N. Mathilda Ave.
San Jose, California 95134 Sunnyvale, California 94089
United States United States
Email: antoni.przygienda@ericsson.com Email: prz@juniper.net
Sam K Aldrin Sam K Aldrin
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, California Mountain View, California
United States United States
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
 End of changes. 26 change blocks. 
58 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/