< draft-ietf-bier-idr-extensions-04.txt		draft-ietf-bier-idr-extensions-05.txt >
	Network Working Group X. Xu, Ed.		Network Working Group X. Xu, Ed.
	Internet-Draft M. Chen		Internet-Draft Alibaba Inc.
	Intended status: Standards Track Huawei		Intended status: Standards Track M. Chen
	Expires: July 13, 2018 K. Keyur Patel		Expires: September 1, 2018 Huawei
			K. Patel
	Arrcus, Inc.		Arrcus, Inc.
	I. Wijnands		I. Wijnands
	Cisco		Cisco
	A. Przygienda		A. Przygienda
	Juniper		Juniper
	January 9, 2018		February 28, 2018
	BGP Extensions for BIER		BGP Extensions for BIER
	draft-ietf-bier-idr-extensions-04		draft-ietf-bier-idr-extensions-05
	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
	describes BGP extensions for advertising the BIER-specific		describes BGP extensions for advertising the BIER-specific
	information. These extensions 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.
			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		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 https://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 July 13, 2018.		This Internet-Draft will expire on September 1, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	(https://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
	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. Deployment Considerations . . . . . . . . . . . . . . . . . . 5		6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 6		9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		10. Normative 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) [I-D.ietf-bier-architecture] is		Bit Index Explicit Replication (BIER) [RFC8279] is a new multicast
	a new multicast forwarding architecture which doesn't require an		forwarding architecture which doesn't require an explicit tree-
	explicit tree-building protocol and doesn't require intermediate		building protocol and doesn't require intermediate routers to
	routers to maintain any multicast state. BIER is applicable in a		maintain any multicast state. BIER is applicable in a multi-tenant
	multi-tenant data center network environment for efficient delivery		data center network environment for efficient delivery of Broadcast,
	of Broadcast, Unknown-unicast and Multicast (BUM) traffic while		Unknown-unicast and Multicast (BUM) traffic while eliminating the
	eliminating the need for maintaining a huge amount of multicast state		need for maintaining a huge amount of multicast state in the
	in the underlay [I-D.ietf-bier-use-cases]. This document describes		underlay. This document describes BGP extensions for advertising the
	BGP extensions for advertising the BIER-specific information. More		BIER-specific information. More specifically, in this document, we
	specifically, in this document, we define a new optional, non-		define a new optional, non- transitive BGP attribute, referred to as
	transitive BGP attribute, referred to as the BIER attribute, to		the BIER attribute, to convey the BIER-specific information such as
	convey the BIER-specific information such as BFR-ID, BitString Length		BFR-ID, BitString Length (BSL) and so on. In addition, this document
	(BSL) and so on. In addition, this document specifies procedures to		specifies procedures to prevent the BIER attribute from "leaking out"
	prevent the BIER attribute from "leaking out" of a BIER domain.		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 [RFC7938]. These		where BGP instead of IGP is used as an underlay [RFC7938]. These
	extensions may also be applicable to other BGP based network		extensions may also be applicable to other BGP based network
	scenarios.		scenarios.
	1.1. 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].
	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 [RFC8279].
	[I-D.ietf-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. In other words, if		/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		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		"BFR-prefix". When creating a BIER attribute, a BFR needs to include
	skipping to change at page 4, line 39 ¶		skipping to change at page 4, line 39 ¶
	Label Range Size: a one-octet field indicating the size of the		Label Range Size: a one-octet field indicating the size of the
	label range.		label range.
	Label Range Base: a 3-octet field where the 20 rightmost bits		Label Range Base: a 3-octet field where the 20 rightmost bits
	represent the first label in the label range while the other 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		MUST be set to 0 when transmitting, and MUST be ignored upon
	receipt.		receipt.
	BSL: a one-octet field indicating the length of the Bitstring in		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		4-octets. The field MUST be filled with one of the valid BSL
	values as specified in [I-D.ietf-bier-architecture]. Upon		values as specified in [RFC8279]. Upon receiving a BSL-TLV
	receiving a BSL-TLV containing an invalid BSL value, it MUST be		containing an invalid BSL value, it MUST be 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
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	with possible values from 1 to 655355 (The value 0 is "reserved".)		with possible values from 1 to 655355 (The value 0 is "reserved".)
	The allocation policy for this field is to be "First Come First		The allocation policy for this field is to be "First Come First
	Serve". Type codes should be allocated for BIER TLV and BIER MPLS		Serve". Type codes should be allocated for BIER TLV and BIER MPLS
	Encapsulation sub-TLV respectively.		Encapsulation sub-TLV respectively.
	9. Security Considerations		9. Security Considerations
	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. Normative References
	10.1. Normative References
	[I-D.ietf-bier-architecture]
	Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
	S. Aldrin, "Multicast using Bit Index Explicit
	Replication", draft-ietf-bier-architecture-08 (work in
	progress), September 2017.
	[I-D.ietf-bier-mpls-encapsulation]
	Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J.,
	Aldrin, S., and I. Meilik, "Encapsulation for Bit Index
	Explicit Replication in MPLS and non-MPLS Networks",
	draft-ietf-bier-mpls-encapsulation-12 (work in progress),
	October 2017.
	[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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://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,
	<https://www.rfc-editor.org/info/rfc4271>.		<https://www.rfc-editor.org/info/rfc4271>.
	10.2. Informative References
	[I-D.ietf-bier-use-cases]
	Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A.,
	Przygienda, T., arkadiy.gulko@thomsonreuters.com, a.,
	Robinson, D., Arya, V., and C. Bestler, "BIER Use Cases",
	draft-ietf-bier-use-cases-05 (work in progress), July
	2017.
	[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of		[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
	BGP for Routing in Large-Scale Data Centers", RFC 7938,		BGP for Routing in Large-Scale Data Centers", RFC 7938,
	DOI 10.17487/RFC7938, August 2016,		DOI 10.17487/RFC7938, August 2016,
	<https://www.rfc-editor.org/info/rfc7938>.		<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		Authors' Addresses
	Xiaohu Xu (editor)		Xiaohu Xu (editor)
	Huawei		Alibaba Inc.
	Email: xuxh.mail@gmail.com		Email: xiaohu.xxh@alibaba-inc.com
	Mach Chen		Mach Chen
	Huawei		Huawei
	Email: mach.chen@huawei.com		Email: mach.chen@huawei.com
	Keyur Patel		Keyur Patel
	Arrcus, Inc.		Arrcus, Inc.
	Email: keyur@arrcus.com		Email: keyur@arrcus.com
End of changes. 16 change blocks.
	63 lines changed or deleted		41 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/