draft-ietf-bier-mld-00.txt   draft-ietf-bier-mld-01.txt 
Network Working Group P. Pfister Network Working Group P. Pfister
Internet-Draft IJ. Wijnands Internet-Draft IJ. Wijnands
Intended status: Standards Track S. Venaas Intended status: Standards Track S. Venaas
Expires: December 31, 2017 Cisco Systems Expires: December 31, 2018 Cisco Systems
C. Wang C. Wang
Z. Zhang Z. Zhang
ZTE Corporation ZTE Corporation
M. Stenberg M. Stenberg
June 29, 2017 June 29, 2018
BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery
Protocols Protocols
draft-ietf-bier-mld-00 draft-ietf-bier-mld-01
Abstract Abstract
This document specifies the ingress part of a multicast flow overlay This document specifies the ingress part of a multicast flow overlay
for BIER networks. Using existing multicast listener discovery for BIER networks. Using existing multicast listener discovery
protocols, it enables multicast membership information sharing from protocols, it enables multicast membership information sharing from
egress routers, acting as listeners, toward ingress routers, acting egress routers, acting as listeners, toward ingress routers, acting
as queriers. Ingress routers keep per-egress-router state, used to as queriers. Ingress routers keep per-egress-router state, used to
construct the BIER bit mask associated with IP multicast packets construct the BIER bit mask associated with IP multicast packets
entering the BIER domain. entering the BIER domain.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 December 31, 2017. This Internet-Draft will expire on December 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
5. Querier and Listener Specifications . . . . . . . . . . . . . 4 5. Querier and Listener Specifications . . . . . . . . . . . . . 4
5.1. Configuration Parameters . . . . . . . . . . . . . . . . 5 5.1. Configuration Parameters . . . . . . . . . . . . . . . . 5
5.2. MLDv2 instances. . . . . . . . . . . . . . . . . . . . . 5 5.2. MLDv2 instances. . . . . . . . . . . . . . . . . . . . . 5
5.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 6 5.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 6
5.2.2. Sending Reports . . . . . . . . . . . . . . . . . . . 6 5.2.2. Sending Reports . . . . . . . . . . . . . . . . . . . 6
5.2.3. Receiving Queries . . . . . . . . . . . . . . . . . . 6 5.2.3. Receiving Queries . . . . . . . . . . . . . . . . . . 7
5.2.4. Receiving Reports . . . . . . . . . . . . . . . . . . 7 5.2.4. Receiving Reports . . . . . . . . . . . . . . . . . . 7
5.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 7 5.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. BIER Use Case in Data Centers . . . . . . . . . . . 9 Appendix A. BIER Use Case in Data Centers . . . . . . . . . . . 10
A.1. Convention and Terminology . . . . . . . . . . . . . . . 11 A.1. Convention and Terminology . . . . . . . . . . . . . . . 12
A.2. BIER in data centers . . . . . . . . . . . . . . . . . . 11 A.2. BIER in data centers . . . . . . . . . . . . . . . . . . 12
A.3. A BIER MLD solution for Virtual Network information . . . 12 A.3. A BIER MLD solution for Virtual Network information . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Bit Index Explicit Replication (BIER - The Bit Index Explicit Replication (BIER - [RFC8279]) forwarding
[I-D.ietf-bier-architecture]) forwarding technique enables IP technique enables IP multicast transport across a BIER domain. When
multicast transport across a BIER domain. When receiving or receiving or originating a packet, ingress routers have to construct
originating a packet, ingress routers have to construct a bit mask a bit mask indicating which BIER egress routers located within the
indicating which BIER egress routers located within the same BIER same BIER domain will receive the packet. A stateless approach would
domain will receive the packet. A stateless approach would consist consist of forwarding all incoming packets toward all egress routers,
in forwarding all incoming packets toward all egress routers, which which would in turn make a forwarding decision based on local
would in turn make a forwarding decision based on local information. information. But any more efficient approach would require ingress
But any more efficient approach would require ingress routers to keep routers to keep some state about egress routers multicast membership
some state about egress routers multicast membership information, information, hence requiring state sharing from egress routers toward
hence requiring state sharing from egress routers toward ingress ingress routers.
routers.
This document specifies how to use the Multicast Listener Discovery This document specifies how to use the Multicast Listener Discovery
protocol version 2 [RFC3810] (resp. the Internet Group Management protocol version 2 [RFC3810] (resp. the Internet Group Management
protocol version 3 [RFC3376]) as the ingress part of a BIER multicast protocol version 3 [RFC3376]) as the ingress part of a BIER multicast
flow overlay (BIER layering is described in flow overlay (BIER layering is described in [RFC8279]) for IPv6
[I-D.ietf-bier-architecture]) for IPv6 (resp. IPv4). It enables (resp. IPv4). It enables multicast membership information sharing
multicast membership information sharing from egress routers, acting from egress routers, acting as listeners, toward ingress routers,
as listeners, toward ingress routers, acting as queriers. Ingress acting as queriers. Ingress routers keep per-egress-router state,
routers keep per-egress-router state, used to construct the BIER bit used to construct the BIER bit mask associated with IP multicast
mask associated with IP multicast packets entering the BIER domain. packets entering the BIER domain.
This specification is applicable to both IP version 4 and version 6. This specification is applicable to both IP version 4 and version 6.
It therefore specifies two separate mechanisms operating It therefore specifies two separate mechanisms operating
independently. For the sake of simplicity, the rest of this document independently. For the sake of simplicity, the rest of this document
uses IPv6 terminology. It can be applied to IPv4 by replacing uses IPv6 terminology. It can be applied to IPv4 by replacing
'MLDv2' with 'IGMPv3', and following specific requirements when 'MLDv2' with 'IGMPv3', and following specific requirements when
explicitly stated. explicitly stated.
2. Terminology 2. Terminology
In this document, the key words "MAY", "MUST", "MUST NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"RECOMMENDED", and "SHOULD", are to be interpreted as described in "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
[RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The terms "Bit-Forwarding Router" (BFR), "Bit-Forwarding Egress The terms "Bit-Forwarding Router" (BFR), "Bit-Forwarding Egress
Router" (BFER), "Bit-Forwarding Ingress Router" (BFIR), "BFR-id" and Router" (BFER), "Bit-Forwarding Ingress Router" (BFIR), "BFR-id" and
"BFR-Prefix" are to be interpreted as described in "BFR-Prefix" are to be interpreted as described in [RFC8279].
[I-D.ietf-bier-architecture].
Additionally, the following definitions are used: Additionally, the following definitions are used:
BIER Multicast Listener Discovery (BMLD): The modified version of BIER Multicast Listener Discovery (BMLD): The modified version of
MLD specified in this document. MLD specified in this document.
BMLD Querier: A BFR implementing the Querier part of this BMLD Querier: A BFR implementing the Querier part of this
specification. A BMLD Node MAY be both a Querier and a Listener. specification. A BMLD Node MAY be both a Querier and a Listener.
BMLD Listener: A BFR implementing the Listener part of this BMLD Listener: A BFR implementing the Listener part of this
skipping to change at page 5, line 9 skipping to change at page 5, line 9
originating multicast traffic, MUST behave as BMLD Queriers. originating multicast traffic, MUST behave as BMLD Queriers.
BMLD Queriers (resp. BMLD Listeners) MUST act as MLDv2 Queriers BMLD Queriers (resp. BMLD Listeners) MUST act as MLDv2 Queriers
(resp. MLDv2 Listeners) as specified in [RFC3810] unless stated (resp. MLDv2 Listeners) as specified in [RFC3810] unless stated
otherwise in this section. otherwise in this section.
5.1. Configuration Parameters 5.1. Configuration Parameters
Both Queriers and Listeners MUST operate as BFIRs and BFERs within Both Queriers and Listeners MUST operate as BFIRs and BFERs within
the BIER domain in order to send and receive BMLD messages. They the BIER domain in order to send and receive BMLD messages. They
MUST therefore be configured accordingly, as specified in MUST therefore be configured accordingly, as specified in [RFC8279].
[I-D.ietf-bier-architecture].
All Listeners MUST be configured with a 'all BMLD Queriers' multicast All Listeners MUST be configured with an 'all BMLD Queriers'
address and the BFR-ids of all the BMLD Queriers. This is used by multicast address and the BFR-ids of all the BMLD Queriers. This is
Listeners to send BMLD reports over BIER toward all Queriers. All used by Listeners to send BMLD reports over BIER toward all Queriers.
Queriers MUST be configured to accept BMLD reports sent to this All Queriers MUST be configured to accept BMLD reports sent to this
address. address.
All Queriers MUST be configured with a 'all BMLD Nodes' multicast All Queriers MUST be configured with an 'all BMLD Nodes' multicast
address and the BFR-ids of all the Queriers and Listeners. This address and the BFR-ids of all the Queriers and Listeners. This
information is used by Queriers to send BMLD queries over BIER toward information is used by Queriers to send BMLD queries over BIER toward
all BMLD Nodes. All BMLD Nodes MUST be configured to accept BMLD all BMLD Nodes. All BMLD Nodes MUST be configured to accept BMLD
queries sent to this address. queries sent to this address.
It may be cumbersone to configure the exact set of BFR-ids for
Queriers and Listeners. One MAY configure the set of BFR-ids to
contain any potentially used BFR-id, perhaps having all bit positions
set. There is no harm in configuring unused BFR-ids. Configuring
the BFR-ids of additional routers would in most cases cause no harm,
as a router would drop the BMLD message unless it is configured as a
Querier or a Listener.
Note that BMLD (unlike MLDv2) makes use of per-instance configured Note that BMLD (unlike MLDv2) makes use of per-instance configured
multicast group addresses rather than well-known addresses so that multicast group addresses rather than well-known addresses so that
multiple instances of BMLD (using different group addresses) can be multiple instances of BMLD (using different group addresses) can be
run simultaneously within the same BIER domain. Configured group run simultaneously within the same BIER domain. Configured group
addresses MAY be obtained from allocated IP prefixes using [RFC3306]. addresses MAY be obtained from allocated IP prefixes using [RFC3306].
One MAY choose to use the well-known MLDv2 addresses in one instance, One MAY choose to use the well-known MLDv2 addresses in one instance,
but different instances MUST use different addresses. but different instances MUST use different addresses.
IP packets coming from outside of the BIER domain and having a IP packets coming from outside of the BIER domain and having a
destination address set to the configured 'all BMLD Queriers' or the destination address set to the configured 'all BMLD Queriers' or the
skipping to change at page 6, line 13 skipping to change at page 6, line 20
for IPv4) backward compatibility procedures. for IPv4) backward compatibility procedures.
5.2.1. Sending Queries 5.2.1. Sending Queries
BMLD Queries are IP packets sent over BIER by BMLD Queriers: BMLD Queries are IP packets sent over BIER by BMLD Queriers:
o Toward all BMLD Nodes (i.e., providing to the BIER Layer the BFR- o Toward all BMLD Nodes (i.e., providing to the BIER Layer the BFR-
ids of all BMLD Nodes). ids of all BMLD Nodes).
o Without the IPv6 router alert option [RFC2711] in the hop-by-hop o Without the IPv6 router alert option [RFC2711] in the hop-by-hop
extension header [RFC2460] (or the IPv4 router alert option extension header [RFC8200] (or the IPv4 router alert option
[RFC2113] for IPv4). [RFC2113] for IPv4).
o With the IP destination address set to the 'all BMLD Nodes' group o With the IP destination address set to the 'all BMLD Nodes' group
address. address.
o With the IP source address set to the BFR-Prefix of the sender. o With the IP source address set to the BFR-Prefix of the sender.
o With a TTL value great enough such that the packet can be received o With a TTL value large enough such that the packet can be received
by all BMLD Nodes, depending on the underlying BIER layer (whether by all BMLD Nodes, depending on the underlying BIER layer (whether
it decrements the IP TTL or not) and the size of the network. The it decrements the IP TTL or not) and the size of the network. The
default value is 64. default value is 64.
5.2.2. Sending Reports 5.2.2. Sending Reports
BMLD Reports are IP packets sent over BIER by BMLD Listeners: BMLD Reports are IP packets sent over BIER by BMLD Listeners:
o Toward all BMLD Queriers (i.e., providing to the BIER layer the o Toward all BMLD Queriers (i.e., providing to the BIER layer the
BFR-ids of all BMLD Queriers). BFR-ids of all BMLD Queriers).
o Without the IPv6 router alert option [RFC2711] in the hop-by-hop o Without the IPv6 router alert option [RFC2711] in the hop-by-hop
extension header [RFC2460] (or the IPv4 router alert option extension header [RFC8200] (or the IPv4 router alert option
[RFC2113] for IPv4). [RFC2113] for IPv4).
o With the IP destination address set to the 'all BMLD Queriers' o With the IP destination address set to the 'all BMLD Queriers'
group address. group address.
o With the IP source address set to the BFR-Prefix of the sender. o With the IP source address set to the BFR-Prefix of the sender.
o With a TTL value great enough such that the packet can be received o With a TTL value large enough such that the packet can be received
by all BMLD Queriers, depending on the underlying BIER layer by all BMLD Queriers, depending on the underlying BIER layer
(whether it decrements the IP TTL or not) and the size of the (whether it decrements the IP TTL or not) and the size of the
network. The default value is 64. network. The default value is 64.
Since the reports may contain a large number of records, they may
become larger than the maximum BIER payload that can be delivered to
all the BMLD Queriers. Hence an implementation will need to either
use a small default maximum size, allow configuration of a maximum
size, or rely on MTU discovery. MTU discovery may be done for a sub-
domain using BIER MTU Discovery [I-D.venaas-bier-mtud]) or for the
set of BMLD Queriers using Path MTU Discovery
[I-D.ietf-bier-path-mtu-discovery]).
5.2.3. Receiving Queries 5.2.3. Receiving Queries
BMLD Queriers and Listeners MUST check the destination address of all BMLD Queriers and Listeners MUST check the destination address of all
the IP packets that are received or forwarded over BIER whenever the IP packets that are received or forwarded over BIER whenever
their own BIER bit is set in the packet. If the destination address their own BIER bit is set in the packet. If the destination address
is equal to the 'all BMLD Nodes' group address the packet is is equal to the 'all BMLD Nodes' group address the packet is
processed as specified in this section. processed as specified in this section.
If the IPv6 (resp. IPv4) packet contains an ICMPv6 (resp. IGMP) If the IPv6 (resp. IPv4) packet contains an ICMPv6 (resp. IGMP)
message of type 'Multicast Listener Query' (resp. of type 'Membership message of type 'Multicast Listener Query' (resp. of type 'Membership
skipping to change at page 8, line 28 skipping to change at page 8, line 46
This specification does not require any action from IANA. This specification does not require any action from IANA.
8. Acknowledgements 8. Acknowledgements
Comments concerning this document are very welcome. Comments concerning this document are very welcome.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-bier-architecture] [I-D.ietf-bier-path-mtu-discovery]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and Mirsky, G., Przygienda, T., and A. Dolganow, "Path Maximum
S. Aldrin, "Multicast using Bit Index Explicit Transmission Unit Discovery (PMTUD) for Bit Index Explicit
Replication", draft-ietf-bier-architecture-07 (work in Replication (BIER) Layer", draft-ietf-bier-path-mtu-
progress), June 2017. discovery-04 (work in progress), June 2018.
[I-D.venaas-bier-mtud]
Venaas, S., Wijnands, I., Ginsberg, L., and M. Sivakumar,
"BIER MTU Discovery", draft-venaas-bier-mtud-01 (work in
progress), June 2018.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
DOI 10.17487/RFC2113, February 1997, DOI 10.17487/RFC2113, February 1997,
<http://www.rfc-editor.org/info/rfc2113>. <https://www.rfc-editor.org/info/rfc2113>.
[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>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<http://www.rfc-editor.org/info/rfc3376>. <https://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
9.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
December 1998, <http://www.rfc-editor.org/info/rfc2460>. Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
9.2. Informative References
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, DOI 10.17487/RFC2711, October 1999, RFC 2711, DOI 10.17487/RFC2711, October 1999,
<http://www.rfc-editor.org/info/rfc2711>. <https://www.rfc-editor.org/info/rfc2711>.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
August 2002, <http://www.rfc-editor.org/info/rfc3306>. August 2002, <https://www.rfc-editor.org/info/rfc3306>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<http://www.rfc-editor.org/info/rfc5015>. <https://www.rfc-editor.org/info/rfc5015>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, DOI 10.17487/RFC7365, October Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, <http://www.rfc-editor.org/info/rfc7365>. 2014, <https://www.rfc-editor.org/info/rfc7365>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <http://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
Appendix A. BIER Use Case in Data Centers Appendix A. BIER Use Case in Data Centers
In current data center virtualization, virtual eXtensible Local Area In current data center virtualization, virtual eXtensible Local Area
Network (VXLAN) [RFC7348] is a kind of network virtualization overlay Network (VXLAN) [RFC7348] is a kind of network virtualization overlay
technology which is overlaid between NVEs and is intended for multi- technology which is overlaid between NVEs and is intended for multi-
tenancy data center networks, whose reference architecture is tenancy data center networks, whose reference architecture is
illustrated as per Figure 1. illustrated as per Figure 1.
+--------+ +--------+ +--------+ +--------+
skipping to change at page 11, line 5 skipping to change at page 12, line 5
The other method is using ingress replication to require each NVE to The other method is using ingress replication to require each NVE to
create a mapping between the VXLAN Network Identifier and the remote create a mapping between the VXLAN Network Identifier and the remote
addresses of NVEs which belong to the same virtual network. When NVE addresses of NVEs which belong to the same virtual network. When NVE
receives BUM traffic from the attached tenant, NVE can encapsulate receives BUM traffic from the attached tenant, NVE can encapsulate
these BUM packets in unicast packets and replicate them and tunnel these BUM packets in unicast packets and replicate them and tunnel
them to different remote NVEs respectively. Although this method can them to different remote NVEs respectively. Although this method can
eliminate the burden of running multicast protocol in the underlay eliminate the burden of running multicast protocol in the underlay
network, it has a significant disadvantage: large waste of bandwidth, network, it has a significant disadvantage: large waste of bandwidth,
especially in big-sized data center where there are many receivers. especially in big-sized data center where there are many receivers.
BIER [I-D.ietf-bier-architecture] is an architecture that provides BIER [RFC8279] is an architecture that provides optimal multicast
optimal multicast forwarding through a "BIER domain" without forwarding through a "BIER domain" without requiring intermediate
requiring intermediate routers to maintain any multicast related per- routers to maintain any multicast related per-flow state. BIER also
flow state. BIER also does not require any explicit tree-building does not require any explicit tree-building protocol for its
protocol for its operation. A multicast data packet enters a BIER operation. A multicast data packet enters a BIER domain at a "Bit-
domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one
BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router
The BFIR router adds a BIER header to the packet. The BIER header adds a BIER header to the packet. The BIER header contains a bit-
contains a bit-string in which each bit represents exactly one BFER string in which each bit represents exactly one BFER to forward the
to forward the packet to. The set of BFERs to which the multicast packet to. The set of BFERs to which the multicast packet needs to
packet needs to be forwarded is expressed by setting the bits that be forwarded is expressed by setting the bits that correspond to
correspond to those routers in the BIER header. Specifically, for those routers in the BIER header. Specifically, for BIER-TE, the
BIER-TE, the BIER header may also contain a bit-string in which each BIER header may also contain a bit-string in which each bit indicates
bit indicates the link the flow passes through. the link the flow passes through.
The following sub-sections try to propose how to take full advantage The following sub-sections try to propose how to take full advantage
of overlay multicast protocol to carry virtual network information, of overlay multicast protocol to carry virtual network information,
and create a mapping between the virtual network information and the and create a mapping between the virtual network information and the
bit-string to implement BUM services in data centers. bit-string to implement BUM services in data centers.
A.1. Convention and Terminology A.1. Convention and Terminology
The terms about NVO3 are defined in [RFC7365]. The most common The terms about NVO3 are defined in [RFC7365]. The most common
terminology used in this appendix is listed below. terminology used in this appendix is listed below.
 End of changes. 38 change blocks. 
83 lines changed or deleted 115 lines changed or added

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