< draft-xu-idr-bier-extensions-00.txt   draft-xu-idr-bier-extensions-01.txt >
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Huawei Internet-Draft M. Chen
Intended status: Standards Track K. Patel Intended status: Standards Track Huawei
Expires: August 20, 2015 Cisco Expires: September 4, 2015 K. Patel
M. Chen
Huawei
I. Wijnands I. Wijnands
Cisco Cisco
February 16, 2015 A. Przygienda
Ericsson
March 3, 2015
BGP Extensions for BIER BGP Extensions for BIER
draft-xu-idr-bier-extensions-00 draft-xu-idr-bier-extensions-01
Abstract Abstract
Bit Index Explicit Replication (BIER) is a new multicast forwarding Bit Index Explicit Replication (BIER) is a new multicast forwarding
architecture which doesn't require an explicit tree-building protocol architecture which doesn't require an explicit tree-building protocol
and doesn't require intermediate routers to maintain any multicast and doesn't require intermediate routers to maintain any multicast
state. BIER is applicable in a multi-tenant data center network state. BIER is applicable in a multi-tenant data center network
envioronment for efficient delivery of Broadcast, Unknown-unicast and environment for efficient delivery of Broadcast, Unknown-unicast and
Multicast (BUM) traffic while eliminating the need for maitaining a Multicast (BUM) traffic while eliminating the need for maintaining a
huge amount of multicast state in an underlay. This document huge amount of multicast state in the underlay. This document
describes BGP extensions for advertising the BIER-specific describes BGP extensions for advertising the BIER-specific
information. These extesnions are applicable in those multi-tenant information. These extensions are applicable in those multi-tenant
data centers where BGP instead of IGP is deployed as an underlay for data centers where BGP instead of IGP is deployed as an underlay for
network reachability advertisement. These extensions may also be network reachability advertisement. These extensions may also be
applicable in other scenarios. applicable in other scenarios.
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 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 August 20, 2015. This Internet-Draft will expire on September 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BIER Path Attribute . . . . . . . . . . . . . . . . . . . . . 3 3. BIER Path Attribute . . . . . . . . . . . . . . . . . . . . . 3
4. Originating BIER Attribute . . . . . . . . . . . . . . . . . 4 4. Originating BIER Attribute . . . . . . . . . . . . . . . . . 4
5. Restrictions on Sending/Receiving . . . . . . . . . . . . . . 5 5. Restrictions on Sending/Receiving . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
Bit Index Explicit Replication (BIER) Bit Index Explicit Replication (BIER)
[I-D.wijnands-bier-architecture] is a new multicast forwarding [I-D.wijnands-bier-architecture] is a new multicast forwarding
architecture which doesn't require an explicit tree-building protocol architecture which doesn't require an explicit tree-building protocol
and doesn't require intermediate routers to maintain any multicast and doesn't require intermediate routers to maintain any multicast
state. BIER is applicable in a multi-tenant data center network state. BIER is applicable in a multi-tenant data center network
envioronment for efficient delivery of Broadcast, Unknown-unicast and environment for efficient delivery of Broadcast, Unknown-unicast and
Multicast (BUM) traffic while eliminating the need for maitaining a Multicast (BUM) traffic while eliminating the need for maintaining a
huge amount of multicast state in an huge amount of multicast state in the
underlay[I-D.kumar-bier-use-cases]. This document describes BGP underlay[I-D.kumar-bier-use-cases]. This document describes BGP
extensions for advertising the BIER-specific information. More extensions for advertising the BIER-specific information. More
specifically, in this document, we define a new optional, non- specifically, in this document, we define a new optional, non-
transitive BGP attribute, referred to as the BIER attribute, to transitive BGP attribute, referred to as the BIER attribute, to
convey the BIER-specific information such as BFR-ID, bitstring length convey the BIER-specific information such as BFR-ID, BitString Length
and so on. In addition, this document specifies procedures to (BSL) and so on. In addition, this document specifies procedures to
prevent the BIER attribute from "leaking out" of a BIER domain . prevent the BIER attribute from "leaking out" of a BIER domain .
These extensions are applicable in those multi-tenant data centers These extensions are applicable in those multi-tenant data centers
where BGP instead of IGP is used as an underlay where BGP instead of IGP is used as an underlay
[I-D.ietf-rtgwg-bgp-routing-large-dc]. These extensions may also be [I-D.ietf-rtgwg-bgp-routing-large-dc]. These extensions may also be
applicable to other BGP based network scenarios. applicable to other BGP based network scenarios.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
This memo makes use of the terms defined in [RFC4271]. This memo makes use of the terms defined in [RFC4271] and
[I-D.wijnands-bier-architecture].
3. BIER Path Attribute 3. BIER Path Attribute
This draft defines a new optional, transitive BGP path attribute, This draft defines a new optional, transitive BGP path attribute,
referred to as the BIER attribute. This attribute can be attached to 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- a BGP UPDATE message by the originator so as to indicate the BIER-
specific information of a particular BFR which is identified by the specific information of a particular BFR which is identified by the
/32 or /128 address prefix contained in the NLRI. /32 or /128 address prefix contained in the NLRI.
The attribute type code for the BIER Attribute is TBD. The value The attribute type code for the BIER Attribute is TBD. The value
field of the BIER Attribute is defined here to contain a set of TLVs. field of the BIER Attribute contains one or more BIER TLV as shown in
Each such TLV is encoded as shown in Figure 1. Figure 1.
0 1 2 3 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 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 | Length | | | Type=TBD | Length | Sub-domain |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-ID | BSL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| Value | | Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
Figure 1:BIER TLV Figure 1:BIER TLV
Type: A single octet encoding the TLV Type. Type: A single octet encoding the BIER TLV Type: TBD.
Length: A single octet encoding the length in octets of the TLV, Length: Two octets encoding the length in octets of the TLV,
including the type and length fields. The length is encoded as an including the type and length fields. The length is encoded as an
unsigned binary integer. (Note that the minimum length is 3, unsigned binary integer. (Note that the minimum length is 7,
indicating that no value field is present.) indicating that no sub-TLV is present.)
Sub-domain: a one-octet field encoding the sub-domain ID
Value: A variable-length field containing zero or more octets. corresponding to the BFR-ID.
This document defines three such TLVs including "BFR-ID TLV" , "BSL
TLV" and "MPLS BIER Encapsulation TLV". The first one is used to
convey the BFR-ID of the BFR which is indicated by the NLRI. The
second one is used to indicate the BitString Length that the BFR
which is indicated by the NLRI can support. The third one is used to
indicate the MPLS label range available for the MPLS-BIER
encapsulation purpose [I-D.wijnands-mpls-bier-encapsulation]. Other
TLVs are to be defined in the future.
The BFR-ID TLV is encoded as follows:
Type:TBD2
Length:5
Value: contains a two-octet BFR-ID.
The BSL TLV is encoded as follows: BFR-ID: a two-octet field encoding the BFR-ID.
Type:TBD3 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 [I-D.wijnands-bier-architecture]. Upon
receiving a BSL-TLV containing an invalid BSL value, it MUST be
ignored.
Length:4 Sub-TLVs: contains one or more sub-TLV. The BIER MPLS
Encapsulation sub-TLV is one of such sub-TLVs.
Value: contains a one-octet BSL which indicates the length of the The BIER MPLS Encapsulation sub-TLV is encoded as follows:
Bitstring in 4-octets.
The BIER MPLS Encapsualtion 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=7 |Lbl Range Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Range Base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2:BIER MPLS Encapsulation sub-TLV
Type:TBD4 Type:TBD
Length:7 Length:7
Value: contains a one-octet Label Range Size field indicating the Label Range Size: a one-octet field indicating the size of the
size of the label range, and a 3-octect Label Rang Base field label range.
where the 20 rightmost bits represent the first label in 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.
4. Originating BIER Attribute 4. Originating BIER Attribute
An implementation that supports the BIER attribute MUST support a An implementation that supports the BIER attribute MUST support a
policy to enable or disable the creation of the BIER attribute and policy to enable or disable the creation of the BIER attribute and
its attachment to specific BGP routes. An implementation MAY disable its attachment to specific BGP routes. An implementation MAY disable
the creation of the BIER attribute unless explicitly configured to do the creation of the BIER attribute unless explicitly configured to do
so otherwise. A BGP speaker MUST only attach the locally created so otherwise. A BGP speaker MUST only attach the locally created
BIER attribute to a BGP UPDATE message in which one of its local BIER attribute to a BGP UPDATE message in which at least one of its
addresses (e.g., a loopback address) is contained in the NLRI. routable addresses (e.g., a loopback address) is contained in the
NLRI. Furthermore, the routable address contained in the NLRI is
RECOMMENDED to be the one used for establishing BGP sessions. In
other words, the routable address is usually used as the BGP nexthop
address of BGP updates advertised by that BGP speaker.
5. Restrictions on Sending/Receiving 5. Restrictions on Sending/Receiving
An implementation that supports the BIER attribute MUST support a An implementation that supports the BIER attribute MUST support a
per-EBGP-session policy, that indicates whether the attribute is per-EBGP-session policy, that indicates whether the attribute is
enabled or disabled for use on that session. The BIER attribute MUST 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 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 configured. If an BIER attribute is received on a BGP session for
which session policy is not configured, then the received attribute which session policy is not configured, then the received attribute
MUST be treated exactly as if it were an unrecognized non-transitive MUST be treated exactly as if it were an unrecognised non-transitive
attribute. That is, "it MUST be quietly ignored and not passed along attribute. That is, "it MUST be quietly ignored and not passed along
to other BGP peers". to other BGP peers".
To prevent the BIER attribute from "leaking out" of an BIER domain, To prevent the BIER attribute from "leaking out" of an BIER domain,
each BGP router on the BIER domain MUST support an outbound route each BGP router on the BIER domain MUST support an outbound route
announcement policy.Such a policy MUST be disabled on each EBGP announcement policy. Such a policy MUST be disabled on each EBGP
session by default unless explicitly configured. session by default unless explicitly configured.
6. Acknowledgements 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) . As for which tunnel type should be used, it could be manually
configured or dynamically negotiated by using the BGP Encapsulation
SAFI mechanism as defined in [RFC5512]. The BIER-specific extensions
to the BGP Encapsulation SAFI would be defined in a future version of
this document.
7. Acknowledgements
TBD. TBD.
7. IANA Considerations 8. IANA Considerations
IANA is requested to assign a codepoint in the "BGP Path Attributes" IANA is requested to assign a codepoint in the "BGP Path Attributes"
registry to the BIER attribute. IANA shall create a registry for registry to the BIER attribute. IANA shall create a registry for
"BGP BIER Attribute Types". The type field consists of a single "BGP BIER Attribute Types". The type field consists of a single
octet, with possible values from 1 to 255. (The value 0 is octet, with possible values from 1 to 255. (The value 0 is
"reserved".) The allocation policy for this field is to be "reserved".) The allocation policy for this field is to be
"Standards Action". Type codes should be allocated for BFR-ID TLV, "Standards Action". Type codes should be allocated for BIER TLV and
BSL TLV and BIER MPLS Encapsualtion TLV respectively. BIER MPLS Encapsulation sub-TLV respectively.
8. Security Considerations 9. Security Considerations
TBD. This document introduces no new security considerations beyond those
already specified in [RFC4271].
9. References 10. References
9.1. Normative References 10.1. Normative References
[I-D.wijnands-bier-architecture] [I-D.wijnands-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-wijnands-bier-architecture-04 (work in Replication", draft-wijnands-bier-architecture-04 (work in
progress), February 2015. progress), February 2015.
[I-D.wijnands-mpls-bier-encapsulation] [I-D.wijnands-mpls-bier-encapsulation]
Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and
S. Aldrin, "Encapsulation for Bit Index Explicit S. Aldrin, "Encapsulation for Bit Index Explicit
Replication in MPLS Networks", draft-wijnands-mpls-bier- Replication in MPLS Networks", draft-wijnands-mpls-bier-
encapsulation-02 (work in progress), December 2014. encapsulation-02 (work in progress), December 2014.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
9.2. Informative References [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512, April 2009.
10.2. Informative References
[I-D.ietf-rtgwg-bgp-routing-large-dc] [I-D.ietf-rtgwg-bgp-routing-large-dc]
Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for
routing in large-scale data centers", draft-ietf-rtgwg- routing in large-scale data centers", draft-ietf-rtgwg-
bgp-routing-large-dc-01 (work in progress), February 2015. bgp-routing-large-dc-01 (work in progress), February 2015.
[I-D.kumar-bier-use-cases] [I-D.kumar-bier-use-cases]
Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A.,
Przygienda, T., arkadiy.gulko@thomsonreuters.com, a., and Przygienda, T., arkadiy.gulko@thomsonreuters.com, a., and
D. Robinson, "BIER Use Cases", draft-kumar-bier-use- D. Robinson, "BIER Use Cases", draft-kumar-bier-use-
cases-02 (work in progress), February 2015. cases-02 (work in progress), February 2015.
Authors' Addresses Authors' Addresses
Xiaohu Xu Xiaohu Xu
Huawei Huawei
Email: xuxiaohu@huawei.com Email: xuxiaohu@huawei.com
Mach Chen
Huawei
Email: mach.chen@huawei.com
Keyur Patel Keyur Patel
Cisco Cisco
Email: keyupate@cisco.com Email: keyupate@cisco.com
Mach Chen
Huawei
Email: mach.chen@huawei.com
IJsbrand Wijnands IJsbrand Wijnands
Cisco Cisco
Email: ice@cisco.com Email: ice@cisco.com
Antoni Przygienda
Ericsson
Email: antoni.przygienda@ericsson.com
 End of changes. 38 change blocks. 
81 lines changed or deleted 112 lines changed or added

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