Network Working Group X. Xu, Ed.
Internet-Draft Alibaba Inc.
Intended status: Standards Track M. Chen
Expires: March 9, 2020 Huawei
K. Patel
Arrcus, Inc.
I. Wijnands
Cisco
A. Przygienda
Juniper
September 6, 2019
BGP Extensions for BIER
draft-ietf-bier-idr-extensions-07
Abstract
Bit Index Explicit Replication (BIER) is a new multicast forwarding
architecture which doesn't require an explicit tree-building protocol
and doesn't require intermediate routers to maintain any multicast
state. BIER is applicable in a multi-tenant data center network
environment for efficient delivery of Broadcast, Unknown-unicast and
Multicast (BUM) traffic while eliminating the need for maintaining a
huge amount of multicast state in the underlay. This document
describes BGP extensions for advertising the BIER-specific
information. These extensions are applicable in those multi-tenant
data centers where BGP instead of IGP is deployed as an underlay for
network reachability advertisement. These extensions may also be
applicable in other scenarios.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Xu, et al. Expires March 9, 2020 [Page 1]
Internet-Draft BGP Extensions for BIER September 2019
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 9, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BIER Path Attribute . . . . . . . . . . . . . . . . . . . . . 3
4. Originating BIER Attribute . . . . . . . . . . . . . . . . . 4
5. Restrictions on Sending/Receiving . . . . . . . . . . . . . . 5
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Bit Index Explicit Replication (BIER) [RFC8279] is a new multicast
forwarding architecture which doesn't require an explicit tree-
building protocol and doesn't require intermediate routers to
maintain any multicast state. BIER is applicable in a multi-tenant
data center network environment for efficient delivery of Broadcast,
Unknown-unicast and Multicast (BUM) traffic while eliminating the
need for maintaining a huge amount of multicast state in the
underlay. This document describes BGP extensions for advertising the
BIER-specific information. More specifically, in this document, we
define a new optional, non- transitive BGP attribute, referred to as
Xu, et al. Expires March 9, 2020 [Page 2]
Internet-Draft BGP Extensions for BIER September 2019
the BIER attribute, to convey the BIER-specific information such as
BFR-ID, BitString Length (BSL) and so on. In addition, this document
specifies procedures to prevent the BIER attribute from "leaking out"
of a BIER domain.
These extensions are applicable in those multi-tenant data centers
where BGP instead of IGP is used as an underlay [RFC7938]. These
extensions may also be applicable to other BGP based network
scenarios.
2. Terminology
This memo makes use of the terms defined in [RFC4271] and [RFC8279].
3. BIER Path Attribute
This draft defines a new optional, transitive BGP path attribute,
referred to as the BIER attribute. This attribute can be attached to
a BGP UPDATE message by the originator so as to indicate the BIER-
specific information of a particular BFR which is identified by the
/32 or /128 address prefix contained in the NLRI. In other words, if
the BIER path attribute is present, the NLRI is treated by BIER as a
"BFR-prefix". When creating a BIER attribute, a BFR needs to include
one BIER TLV for every <Sub-domain, BFR-ID> pair that it supports.
The attribute type code for the BIER Attribute is TBD. The value
field of the BIER Attribute contains one or more BIER TLV as shown in
Figure 1.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain | BFR-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
Figure 1:BIER TLV
Type: Two octets encoding the BIER TLV Type: TBD.
Length: Two octets encoding the length in octets of the TLV,
including the type and length fields. The length is encoded as an
unsigned binary integer. (Note that the minimum length is 8,
indicating that no sub-TLV is present.)
Xu, et al. Expires March 9, 2020 [Page 3]
Internet-Draft BGP Extensions for BIER September 2019
Sub-domain: a one-octet field encoding the sub-domain ID
corresponding to the BFR-ID.
BFR-ID: a two-octet field encoding the BFR-ID.
Sub-TLVs: contains one or more sub-TLV. The BIER MPLS
Encapsulation sub-TLV is one of such sub-TLVs.
The BIER MPLS Encapsulation sub-TLV is encoded as follows:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length=12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Range Base |Lbl Range Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2:BIER MPLS Encapsulation sub-TLV
Type:TBD
Length:12
Label Range Size: a one-octet field indicating the size of the
label range.
Label Range Base: a 3-octet field where the 20 rightmost bits
represent the first label in the label range while the other bits
MUST be set to 0 when transmitting, and MUST be ignored upon
receipt.
BSL: a one-octet field indicating the length of the Bitstring in
4-octets. The field MUST be filled with one of the valid BSL
values as specified in [RFC8279]. Upon receiving a BSL-TLV
containing an invalid BSL value, it MUST be ignored.
4. Originating BIER Attribute
An implementation that supports the BIER attribute MUST support a
policy to enable or disable the creation of the BIER attribute and
its attachment to specific BGP routes. An implementation MAY disable
the creation of the BIER attribute unless explicitly configured to do
so otherwise. A BGP speaker MUST only attach the locally created
BIER attribute to a BGP UPDATE message in which at least one of its
BFR-prefixes is contained in the NLRI
Xu, et al. Expires March 9, 2020 [Page 4]
Internet-Draft BGP Extensions for BIER September 2019
5. Restrictions on Sending/Receiving
An implementation that supports the BIER attribute MUST support a
per-EBGP-session policy, that indicates whether the attribute is
enabled or disabled for use on that session. The BIER attribute MUST
NOT be sent on any EBGP peers for which the session policy is not
configured. If an BIER attribute is received on a BGP session for
which session policy is not configured, then the received attribute
MUST be treated exactly as if it were an unrecognised non-transitive
attribute. That is, "it MUST be quietly ignored and not passed along
to other BGP peers".
To prevent the BIER attribute from "leaking out" of an BIER domain,
each BGP router on the BIER domain MUST support an outbound route
announcement policy. Such a policy MUST be disabled on each EBGP
session by default unless explicitly configured.
6. Deployment Considerations
It's assumed by this document that the BIER domain is aligned with
the Administrative Domain (AD) which are composed of multiple ASes
(either private or public ASes). Use of the BIER attribute in other
scenarios is outside the scope of this document.
Since the BIER attribute is an optional, transitive BGP path
attribute, a non-BFR BGP speakers could still advertise the received
route with a BIER attribute. This is desirable in the incremental
deployment scenario where a BGP speaker could tunnel a BIER packet or
the payload of a BIER packet to a BFER directly if the BGP next-hop
of the route for that BFER is a non-BFR. Furthermore, a BGP speaker
is allowed to tunnel a BIER packet to the BGP next-hop if these two
BFR-capable BGP neighbors are not directly connected (e.g., multi-hop
EBGP).
7. Acknowledgements
Thanks a lot for Eric Rosen and Peter Psenak for their valuable
comments on this document.
8. IANA Considerations
IANA is requested to assign a codepoint in the "BGP Path Attributes"
registry to the BIER attribute. IANA shall create a registry for
"BGP BIER Attribute Types". The type field consists of two octets,
with possible values from 1 to 655355 (The value 0 is "reserved".)
The allocation policy for this field is to be "First Come First
Serve". Type codes should be allocated for BIER TLV and BIER MPLS
Encapsulation sub-TLV respectively.
Xu, et al. Expires March 9, 2020 [Page 5]
Internet-Draft BGP Extensions for BIER September 2019
9. Security Considerations
This document introduces no new security considerations beyond those
already specified in [RFC4271].
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
Authors' Addresses
Xiaohu Xu (editor)
Alibaba Inc.
Email: xiaohu.xxh@alibaba-inc.com
Mach Chen
Huawei
Email: mach.chen@huawei.com
Keyur Patel
Arrcus, Inc.
Email: keyur@arrcus.com
Xu, et al. Expires March 9, 2020 [Page 6]
Internet-Draft BGP Extensions for BIER September 2019
IJsbrand Wijnands
Cisco
Email: ice@cisco.com
Antoni Przygienda
Juniper
Email: prz@juniper.net
Xu, et al. Expires March 9, 2020 [Page 7]