< draft-ietf-bier-idr-extensions-01.txt   draft-ietf-bier-idr-extensions-02.txt >
Network Working Group X. Xu, Ed. Network Working Group X. Xu, Ed.
Internet-Draft M. Chen Internet-Draft M. Chen
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: January 1, 2017 K. Patel Expires: July 21, 2017 K. Keyur Patel
Arrcus, Inc.
I. Wijnands I. Wijnands
Cisco Cisco
A. Przygienda A. Przygienda
Juniper Juniper
June 30, 2016 January 17, 2017
BGP Extensions for BIER BGP Extensions for BIER
draft-ietf-bier-idr-extensions-01 draft-ietf-bier-idr-extensions-02
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
environment 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 maintaining a Multicast (BUM) traffic while eliminating the need for maintaining a
huge amount of multicast state in the underlay. This document huge amount of multicast state in the underlay. This document
skipping to change at page 1, line 46 skipping to change at page 1, line 47
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 January 1, 2017. This Internet-Draft will expire on July 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
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
skipping to change at page 2, line 52 skipping to change at page 2, line 52
routers to maintain any multicast state. BIER is applicable in a routers to maintain any multicast state. BIER is applicable in a
multi-tenant data center network environment for efficient delivery multi-tenant data center network environment for efficient delivery
of Broadcast, Unknown-unicast and Multicast (BUM) traffic while of Broadcast, Unknown-unicast and Multicast (BUM) traffic while
eliminating the need for maintaining a huge amount of multicast state eliminating the need for maintaining a huge amount of multicast state
in the underlay [I-D.ietf-bier-use-cases]. This document describes in the underlay [I-D.ietf-bier-use-cases]. This document describes
BGP extensions for advertising the BIER-specific information. More BGP 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
(BSL) 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 [RFC7938]. These
[I-D.ietf-rtgwg-bgp-routing-large-dc]. These extensions may also be extensions may also be applicable to other BGP based network
applicable to other BGP based network scenarios. 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] and This memo makes use of the terms defined in [RFC4271] and
skipping to change at page 4, line 6 skipping to change at page 4, line 4
| Sub-TLVs | | Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
Figure 1:BIER TLV Figure 1:BIER TLV
Type: Two octets encoding the BIER TLV Type: TBD. Type: Two octets encoding the BIER TLV Type: TBD.
Length: Two octets 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 8, unsigned binary integer. (Note that the minimum length is 8,
indicating that no sub-TLV is present.) indicating that no sub-TLV is present.)
Sub-domain: a one-octet field encoding the sub-domain ID Sub-domain: a one-octet field encoding the sub-domain ID
corresponding to the BFR-ID. corresponding to the BFR-ID.
BFR-ID: a two-octet field encoding the BFR-ID. BFR-ID: a two-octet field encoding the BFR-ID.
Sub-TLVs: contains one or more sub-TLV. The BIER MPLS Sub-TLVs: contains one or more sub-TLV. The BIER MPLS
Encapsulation sub-TLV is one of such sub-TLVs. Encapsulation sub-TLV is one of such sub-TLVs.
The BIER MPLS Encapsulation sub-TLV is encoded as follows: The BIER MPLS Encapsulation sub-TLV is encoded as follows:
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=TBD | Length=8 | | Type=TBD | Length=12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Range Base |Lbl Range Size | | Label Range Base |Lbl Range Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSL | Reserved | | BSL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2:BIER MPLS Encapsulation sub-TLV Figure 2:BIER MPLS Encapsulation sub-TLV
Type:TBD Type:TBD
Length:12 Length:12
skipping to change at page 5, line 6 skipping to change at page 4, line 51
ignored. ignored.
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 at least one of its BIER attribute to a BGP UPDATE message in which at least one of its
BFR-prefixes is contained in the NLRI. BFR-prefixes is contained in the NLRI
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 unrecognised non-transitive MUST be treated exactly as if it were an unrecognised non-transitive
skipping to change at page 5, line 40 skipping to change at page 5, line 37
scenarios is outside the scope of this document. scenarios is outside the scope of this document.
Since the BIER attribute is an optional, transitive BGP path Since the BIER attribute is an optional, transitive BGP path
attribute, a non-BFR BGP speakers could still advertise the received attribute, a non-BFR BGP speakers could still advertise the received
route with a BIER attribute. This is desirable in the incremental route with a BIER attribute. This is desirable in the incremental
deployment scenario where a BGP speaker could tunnel a BIER packet or 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 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 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 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 BFR-capable BGP neighbors are not directly connected (e.g., multi-hop
EBGP) . EBGP).
7. Acknowledgements 7. Acknowledgements
Thanks a lot for Eric Rosen and Peter Psenak for their valuable Thanks a lot for Eric Rosen and Peter Psenak for their valuable
comments on this document. comments on this document.
8. 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
skipping to change at page 6, line 21 skipping to change at page 6, line 17
This document introduces no new security considerations beyond those This document introduces no new security considerations beyond those
already specified in [RFC4271]. already specified in [RFC4271].
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-bier-architecture] [I-D.ietf-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-ietf-bier-architecture-03 (work in Replication", draft-ietf-bier-architecture-05 (work in
progress), January 2016. progress), October 2016.
[I-D.ietf-bier-mpls-encapsulation] [I-D.ietf-bier-mpls-encapsulation]
Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and Wijnands, I., 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", draft-ietf-bier-mpls- Explicit Replication in MPLS and non-MPLS Networks",
encapsulation-04 (work in progress), April 2016. draft-ietf-bier-mpls-encapsulation-06 (work in progress),
December 2016.
[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>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>. <http://www.rfc-editor.org/info/rfc4271>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-bier-use-cases] [I-D.ietf-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., Przygienda, T., arkadiy.gulko@thomsonreuters.com, a.,
Robinson, D., Arya, V., and C. Bestler, "BIER Use Cases", Robinson, D., Arya, V., and C. Bestler, "BIER Use Cases",
draft-ietf-bier-use-cases-02 (work in progress), January draft-ietf-bier-use-cases-04 (work in progress), January
2016. 2017.
[I-D.ietf-rtgwg-bgp-routing-large-dc] [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for BGP for Routing in Large-Scale Data Centers", RFC 7938,
routing in large-scale data centers", draft-ietf-rtgwg- DOI 10.17487/RFC7938, August 2016,
bgp-routing-large-dc-11 (work in progress), June 2016. <http://www.rfc-editor.org/info/rfc7938>.
Authors' Addresses Authors' Addresses
Xiaohu Xu (editor) Xiaohu Xu (editor)
Huawei Huawei
Email: xuxiaohu@huawei.com Email: xuxiaohu@huawei.com
Mach Chen Mach Chen
Huawei Huawei
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Keyur Patel Keyur Patel
Cisco Arrcus, Inc.
Email: keyupate@cisco.com Email: keyur@arrcus.com
IJsbrand Wijnands IJsbrand Wijnands
Cisco Cisco
Email: ice@cisco.com Email: ice@cisco.com
Antoni Przygienda Antoni Przygienda
Juniper Juniper
Email: prz@juniper.net Email: prz@juniper.net
 End of changes. 17 change blocks. 
27 lines changed or deleted 28 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/