< draft-przygienda-bier-isis-ranges-01.txt		draft-przygienda-bier-isis-ranges-02.txt >
	Internet Engineering Task Force A. Przygienda		Internet Engineering Task Force A. Przygienda
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track L. Ginsberg		Intended status: Standards Track L. Ginsberg
	Expires: April 26, 2015 Cisco Systems		Expires: August 3, 2015 Cisco Systems
	S. Aldrin		S. Aldrin
	Huawei		Huawei
	J. Zhang		J. Zhang
	Juniper Networks, Inc.		Juniper Networks, Inc.
	October 23, 2014		January 30, 2015
	BIER support via ISIS		BIER support via ISIS
	draft-przygienda-bier-isis-ranges-01		draft-przygienda-bier-isis-ranges-02
	Abstract		Abstract
	Specification of an ISIS extension to support BIER domains.		Specification of an ISIS extension to support BIER domains and sub-
			domains.
	Requirements Language		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] .
	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
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 42 ¶
	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 April 26, 2015.		This Internet-Draft will expire on August 3, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. BIER Domains in Extended Reachability TLVs . . . . . . . 4		4.1. BIER Domains and Sub-Domains . . . . . . . . . . . . . . 4
	4.2. BIER Domains . . . . . . . . . . . . . . . . . . . . . . 4
	5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4		5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5.1. Enabling a BIER Domain . . . . . . . . . . . . . . . . . 4		5.1. Enabling a BIER Sub-Domain . . . . . . . . . . . . . . . 5
	5.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5		5.2. Multi Topology and Sub-Domain . . . . . . . . . . . . . . 5
	5.3. Label Advertisements for MPLS encapsulated BIER domains . 5		5.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5
	5.3.1. Special Consideration . . . . . . . . . . . . . . . . 5		5.4. Tree Type . . . . . . . . . . . . . . . . . . . . . . . . 5
	5.4. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 5		5.5. Label Advertisements for MPLS encapsulated BIER sub-
	5.5. Flooding . . . . . . . . . . . . . . . . . . . . . . . . 6		domains . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 6		5.5.1. Special Consideration . . . . . . . . . . . . . . . . 6
	6.1. BIER Info sub-TLV . . . . . . . . . . . . . . . . . . . . 6		5.6. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 6
	6.2. BIER MPLS Encapsulation sub-sub-TLV . . . . . . . . . . . 7		5.7. Flooding . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5.8. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7
	9. Normative References . . . . . . . . . . . . . . . . . . . . 8		6.1. BIER Info sub-TLV . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		6.2. BIER MPLS Encapsulation sub-sub-TLV . . . . . . . . . . . 8
			6.3. Optional BIER sub-domain Tree Type sub-sub-TLV . . . . . 9
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
			8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
			9. Normative References . . . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Bit Index Explicit Replication (BIER)		Bit Index Explicit Replication (BIER)
	[I-D.draft-wijnands-bier-architecture-00] defines an architecture		[I-D.draft-wijnands-bier-architecture-02] defines an architecture
	where all intended multicast receivers are encoded as bitmask in the		where all intended multicast receivers are encoded as bitmask in the
	Multicast packet header within different encapsulations such as		Multicast packet header within different encapsulations such as
	[I-D.draft-wijnands-mpls-bier-encapsulation-01]. A router that		[I-D.draft-wijnands-mpls-bier-encapsulation-02]. A router that
	receives such a packet will forward the packet based on the Bit		receives such a packet will forward the packet based on the Bit
	Position in the packet header towards the receiver(s), following a		Position in the packet header towards the receiver(s), following a
	precomputed tree for each of the bits in the packet. Each receiver		precomputed tree for each of the bits in the packet. Each receiver
	is represented by a unique bit in the bitmask.		is represented by a unique bit in the bitmask.
	This document presents first attempt at necessary extensions to the		This document presents necessary extensions to the currently deployed
	currently deployed ISIS for IP [RFC1195] protocol to support		ISIS for IP [RFC1195] protocol to support distribution of information
	distribution of information necessary for operation of BIER domains.		necessary for operation of BIER domains and sub-domains. This
	This document defines a new TLV to be advertised by every router		document defines a new TLV to be advertised by every router
	participating in such BIER domains.		participating in BIER signaling.
	2. Terminology		2. Terminology
	Some of the terminology specified in		Some of the terminology specified in
	[I-D.draft-wijnands-bier-architecture-00] is replicated here and		[I-D.draft-wijnands-bier-architecture-02] is replicated here and
	extended by necessary definitions:		extended by necessary definitions:
	BIER: Bit Index Explicit Replication (The overall architecture of		BIER: Bit Index Explicit Replication (The overall architecture of
	forwarding multicast using a Bit Position).		forwarding multicast using a Bit Position).
	BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn		BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn
	about BFER's).		about BFER's).
	BM: Bit Mask (A bit stream of a certain fixed length. Each Bit
	represents a receiver).
	P-BM: Packet Bit Mask (A Bit Mask included in the Multicast Packet).
	BP: Bit Position (A single Bit from the Bit Mask that represents a
	receiver).
	BFR: Bit Forwarding Router (A router that participates in Bit Index		BFR: Bit Forwarding Router (A router that participates in Bit Index
	Multipoint Forwarding).		Multipoint Forwarding). A BFR is identified by a unique BFR-
			prefix in a BIER domain.
	BFIR: Bit Forwarding Ingress Router (The ingress border router that		BFIR: Bit Forwarding Ingress Router (The ingress border router that
	inserts the BM into the packet).		inserts the BM into the packet).
	BFER: Bit Forwarding Egress Router. A router that participates in		BFER: Bit Forwarding Egress Router. A router that participates in
	Bit Index Forwarding as leaf. Each BFER must be a BFR.		Bit Index Forwarding as leaf. Each BFER must be a BFR. Each BFER
			must have a valid BFR-id assigned.
	BFT: Bit Forwarding Tree used to reach all BFERs in a domain.		BFT: Bit Forwarding Tree used to reach all BFERs in a domain.
	BIFT: Bit Index Forwarding Table (A Bit index forwarding table).		BIFT: Bit Index Forwarding Table.
	BMS: Bit Mask Set. Set containing bit positions of all BFER		BMS: Bit Mask Set. Set containing bit positions of all BFER
	participating in a set.		participating in a set.
	BMP: Bit Mask Position, a given bit in a BMS.		BMP: Bit Mask Position, a given bit in a BMS.
	Invalid BMP: Unassigned Bit Mask Position, consisting of all 0s.		Invalid BMP: Unassigned Bit Mask Position, consisting of all 0s.
	Invalid BFR-id: Unassigned BFR-id, consisting of all 0s.		IGP signalled BIER domain: A BIER underlay where the BIER
			synchronization information is carried in IGP. Observe that a
			multi-topology is NOT a separate BIER domain in IGP.
	IGP signalled BIER domain: A BIER domain information carried in IGP		BIER sub-domain: A further distinction within a BIER domain
	and identified by its multi-topology and bitmask length.		identified by its unique sub-domain identifier. A BIER sub-domain
			can support multiple BitString Lengths.
			BFR-id: An optional, unique identifier for a BFR within a BIER sub-
			domain.
			Invalid BFR-id: Unassigned BFR-id, consisting of all 0s.
	3. IANA Considerations		3. IANA Considerations
	This document adds the following new sub-TLVs to the registry of sub-		This document adds the following new sub-TLVs to the registry of sub-
	TLVs for TLVs 235, 237 [RFC5120] and TLVs 135,236		TLVs for TLVs 235, 237 [RFC5120] and TLVs 135,236
	[RFC5305],[RFC5308].		[RFC5305],[RFC5308].
	Value: 32 (suggested - to be assigned by IANA)		Value: 32 (suggested - to be assigned by IANA)
	Name: BIER Info		Name: BIER Info
	4. Concepts		4. Concepts
	4.1. BIER Domains in Extended Reachability TLVs		4.1. BIER Domains and Sub-Domains
	This draft introduces a sub-TLV in the extended reachability TLVs to		An ISIS signalled BIER domain is aligned with the scope of
	distribute information about BIER domains and services they carry.		distribution of BFR-prefixes that identify the BFRs within ISIS.
	To satisfy the requirements for BIER prefixes per		ISIS acts in such a case as the according BIER underlay.
	[I-D.draft-wijnands-bier-architecture-00] additional information may
	be carried in [I-D.draft-ginsberg-isis-prefix-attributes].
	4.2. BIER Domains		Within such a domain, ISIS extensions are capable of carrying BIER
			information for multiple BIER sub-domains. Each sub-domain is
			uniquely identified by its subdomain-id and each subdomain can reside
			in any of the ISIS topologies [RFC5120]. The mapping of sub-domains
			to topologies is a local decision of each BFR currently but is
			advertised throughout the domain to ensure routing consistency.
	ISIS extensions are capable of carrying BIER information not only for		Each BIER sub-domain has as its unique attributes the encapsulation
	a single BIER domains but for multiple ones. A BIER domain in ISIS		used and the type of tree it is using to forward BIER frames
	is currently always uniquely identified by the tuple of multi-		(currently always SPF). Additionally, per supported bitstring length
	topology MT and bitmask length ML it belongs to denoted as <MT,ML>.		in the sub-domain, each router will advertise the necessary label
			ranges to support it.
	Each such domain itself has as its unique attributes the		This RFC introduces a sub-TLV in the extended reachability TLVs to
	encapsulation used and the type of tree it is using to forward BIER		distribute such information about BIER sub-domains. To satisfy the
	frames (currently always SPF).		requirements for BIER prefixes per
			[I-D.draft-wijnands-bier-architecture-02] additional information will
			be carried in [I-D.draft-ginsberg-isis-prefix-attributes].
	5. Procedures		5. Procedures
			5.1. Enabling a BIER Sub-Domain
	5.1. Enabling a BIER Domain		A given sub-domain with identifier BS with supported bitstring
			lengths MLs in a multi-topology MT [RFC5120] is denoted further as
			<MT,SD,MLs> and is normally not advertised to preserve the scaling of
			the protocol (i.e. ISIS carries no TLVs containing any of the
			elements related to <MT,SD>) and is enabled by a first BIER sub-TLV
			(Section 6.1) containing <MT,SD> being advertised into the area. The
			trigger itself is outside the scope of this RFC but can be for
			example a VPN desiring to initiate a BIER sub-domain as MI-PMSI
			[RFC6513] tree. It is outside the scope of this document to describe
			what trigger for a router capable of participating in <MT,SD> is used
			to start the origination of the necessary information to join into
			it.
	A given domain with masklength ML in a multi-topology MT [RFC5120]		5.2. Multi Topology and Sub-Domain
	(denoted as <MT,ML>) is normally not advertised to preserve the
	scaling of the protocol (i.e. ISIS carries no TLVs containing any of
	the elements related to <MT,ML>) and is enabled by a first BIER sub-
	TLV (Section 6.1) containing <MT,ML> being advertised into the area.
	The trigger itself is outside the scope of this draft but can be for
	example a VPN desiring to initiate a BIER layer as MI-PMSI [RFC6513]
	tree. It is outside the scope of this document to describe what
	trigger for a router capable of participating <MT,ML> is used to
	start the origination of the necessary information to join into it.
	5.2. Encapsulation		All routers in the flooding scope of the BIER TLVs MUST advertise a
			sub-domain within the same multi-topology. A router discovering a
			sub-domain advertised within a topology that is different from its
			own MUST report a misconfiguration of a specific sub-domain. Each
			router MUST compute BFTs for a sub-domain using only routers
			advertising it in the same topology.
	All routers in the flooding scope of the BIER TLVs SHOULD advertise		5.3. Encapsulation
	the same encapsulation for a given <MT,ML>. A router discovering
			All routers in the flooding scope of the BIER TLVs MUST advertise the
			same encapsulation for a given <MT,SD>. A router discovering
	encapsulation advertised that is different from its own MUST report a		encapsulation advertised that is different from its own MUST report a
	misconfiguration of a specific <MT,ML>. Each router MUST compute		misconfiguration of a specific <MT,SD>. Each router MUST compute
	BFTs for <MT,ML> using only routers having the same encapsulation as		BFTs for <MT,SD> using only routers having the same encapsulation as
	its own advertised encapsulation in BIER sub-TLV for <MT,ML>.		its own advertised encapsulation in BIER sub-TLV for <MT,SD>.
	5.3. Label Advertisements for MPLS encapsulated BIER domains		5.4. Tree Type
			All routers in the flooding scope of the BIER TLVs MUST advertise the
			same tree type for a given <MT,SD>. In case of mismatch the behavior
			is analogous to Section 5.3.
			5.5. Label Advertisements for MPLS encapsulated BIER sub-domains
	Each router MAY advertise within the BIER MPLS Encapsulation sub-sub-		Each router MAY advertise within the BIER MPLS Encapsulation sub-sub-
	TLV (Section 6.2) of a BIER Info sub-TLV (Section 6.1) for <MT,ML>		TLV (Section 6.2) of a BIER Info sub-TLV (Section 6.1, denoted as
	(denoted further as TLV<MT,ML>) a valid starting label value and a		TLV<MT,SD>) for <MT,SD> for every supported bitstring length a valid
	non-zero range length. It MUST advertise a valid label value and a		starting label value and a non-zero range length. It MUST advertise
	non-zero range length in case it has computed itself as being on the		at least one valid label value and a non-zero range length for the
	BFT rooted at any of the BFRs with valid BFR-ids (except itself if it		required bitstring lengths per
	does NOT have a valid BFR-id) participating in <MT,ML>.		[I-D.draft-wijnands-bier-architecture-02] in case it has computed
			itself as being on the BFT rooted at any of the BFRs with valid BFR-
			ids (except itself if it does NOT have a valid BFR-id) participating
			in <MT,SD>.
	A router CAN decide to not advertise its TLV<MT,ML> if it does not		A router MAY decide to not advertise the BIER Info sub-TLV
	want to participate in the domain due to resource constraints, label		(Section 6.1) for <MT,SD> if it does not want to participate in the
	space optimization, administrative configuration or any other		sub-domain due to resource constraints, label space optimization,
	reasons.		administrative configuration or any other reasons.
	5.3.1. Special Consideration		5.5.1. Special Consideration
	A router MUST advertise for <MT,ML> label range size that guarantees		A router MUST advertise for each bitstring length it supports in
	to cover the maximum BFR-id injected into <MT,ML> (which implies a		<MT,SD> a label range size that guarantees to cover the maximum BFR-
	certain set id as described in		id injected into <MT,SD> (which implies a certain maximum set id per
	[I-D.draft-wijnands-bier-architecture-00]). Any router that violates		bitstring length as described in
	this condition MUST be excluded from BIER BFTs for <MT,ML>.		[I-D.draft-wijnands-bier-architecture-02]). Any router that violates
			this condition MUST be excluded from BIER BFTs for <MT,SD>.
	5.4. BFR-id Advertisements		5.6. BFR-id Advertisements
	Each BFER MAY advertise with its TLV<MT,ML> the BFR-id that it has		Each BFER MAY advertise with its TLV<MT,SD> the BFR-id that it has
	administratively chosen.		administratively chosen.
	If a router discovers that two BFRs it can reach advertise the same		If a router discovers that two BFRs it can reach advertise the same
	value for BFR-id for <MT,ML>, it MUST report a misconfiguration and		value for BFR-id for <MT,SD>, it MUST report a misconfiguration and
	disregard those routers for all BIER calculations and procedures for		disregard those routers for all BIER calculations and procedures for
	<MT,ML> to align with [I-D.draft-wijnands-bier-architecture-00]. It		<MT,SD> to align with [I-D.draft-wijnands-bier-architecture-02]. It
	is worth observing that based on this procedure routers with		is worth observing that based on this procedure routers with
	colliding BFR-id assignments in <MT,ML> MAY still act as BFIRs in		colliding BFR-id assignments in <MT,SD> MAY still act as BFIRs in
	<MT,ML> but will be never able to receive traffic from other BFRs in		<MT,SD> but will be never able to receive traffic from other BFRs in
	<MT,ML>.		<MT,SD>.
	5.5. Flooding		5.7. Flooding
	BIER domain information SHOULD change and force flooding		BIER domain information SHOULD change and force flooding
	infrequently. Further discussion TBD.		infrequently. Especially, the router SHOULD make every possible
			attempt to bundle all the changes necessary to sub-domains and ranges
			advertised with those into least possible updates.
			5.8. Version
			This RFC specifies Version 0 of the BIER extension encodings. Packet
			encoding supports introduction of future, higher versions with e.g.
			new sub-sub-TLVs or redefining reserved bits that can maintain the
			compatiblity to Version 0 or choose to indicate that the
			compatibility cannot be maintained anymore (changes that cannot work
			with the provided encoding would necessitate obviously introduction
			of completely new sub-TLV for BIER).
			This kind of 'versioning' allows to introduce e.g. backwards-
			compatible automatic assignment of unique BFR-ids within sub-domains
			or addition of optional sub-sub-TLVs that can be ignored by version 0
			BIER routers without the danger of incompatiblity.
			This is a quite common technique in software development today to
			maintain and extend backwards compatible APIs.
	6. Packet Formats		6. Packet Formats
	All ISIS BIER information is carried within the TLVs 235, 237		All ISIS BIER information is carried within the TLVs 235, 237
	[RFC5120] and TLVs 135,236 [RFC5305],[RFC5308].		[RFC5120] and TLVs 135,236 [RFC5305], [RFC5308].
	6.1. BIER Info sub-TLV		6.1. BIER Info sub-TLV
	This sub-TLV carries the information for the BIER domains that the		This sub-TLV carries the information for the BIER sub-domains that
	router participates in as BFR. It can repeat multiple times for		the router participates in as BFR. It can repeat multiple times for
	different domain <MT,ML> combinations. If the same <MT,ML> domain is		different sub-domain <MT,SD> combinations.
	advertised multiple times with different encapsulations, the result
	is unspecified.
	The sub-TLV carries a single <MT,ML> combination followed by optional		The sub-TLV carries a single <MT,SD> combination followed by optional
	sub-sub-TLVs specified within its context such as e.g. BIER MPLS		sub-sub-TLVs specified within its context such as e.g. BIER MPLS
	Encapsulation per Section 6.2.		Encapsulation per Section 6.2.
	0 1 2		On violation of any of the following conditions, the receiving router
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3		SHOULD signal a misconfiguration condition. Further results are
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		unspecified unless described in the according section of this RFC:
	| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		o The subdomain-id MUST be included only within a single topology.
	| BM Len|Reservd| BFR-id |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		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 | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|Ver|C| Reserved| subdomain-id | BFR-id |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: as indicated in IANA section.		Type: as indicated in IANA section.
	Length: 1 octet.		Length: 1 octet.
	Local BitMask Length (BM Len): Bitmask length for this BIER domain		Version: Version of the BIER TLV advertised, must be 0 on
	that this router is advertising per		transmission by router implementing this RFC. Behavior on
	[I-D.draft-wijnands-mpls-bier-encapsulation-01]. 4 bits.		reception depends on the 'C' bit. 2 bits
	Reserved reserved, must be 0 on transmission, ignored on reception.		C-BIT: Compatibility bit indicating that the TLV can be interpreted
	4 bits		by routers implementing lower than the advertised version. Router
			implementing this version of the RFC MUST set it to 1. On
			reception, IF the version of the protocol is higher than 0 AND the
			bit is set (i.e. its value is 1), the TLV MUST be processed
			normally, IF the bit is clear (i.e. its value is 0), the TLV MUST
			be ignored for further processing completely independent of the
			advertised version. When processing this sub-TLV with
			compatibility bit set, all sub-sub-TLV of unknown type MUST and
			CAN be safely ignored. 1 bit
	BFR-id A 2 octet field encoding the BFR-id, as documented in		Reserved: reserved, must be 0 on transmission, ignored on reception.
	[I-D.draft-wijnands-bier-architecture-00]. If set to the invalid		May be used in future versions. 5 bits
	BFR-id advertising router is not owning any BFR-id.
			subdomain-id: Unique value identifying the BIER sub-domain. 1 octet
			BFR-id: A 2 octet field encoding the BFR-id, as documented in
			[I-D.draft-wijnands-bier-architecture-02]. If set to the invalid
			BFR-id advertising router is not owning a BFR-id in the sub-
			domain.
	6.2. BIER MPLS Encapsulation sub-sub-TLV		6.2. BIER MPLS Encapsulation sub-sub-TLV
	This sub-sub-TLV carries the information for the BIER MPLS		This sub-sub-TLV carries the information for the BIER MPLS
	encapsulations for a certain <MT,ML> and is carried within the BIER		encapsulation and the necessary label ranges per bitstring length for
	Info sub-TLV (Section 6.1) that the router participates in as BFR.		a certain <MT,SD> and is carried within the BIER Info sub-TLV
	It can repeat only once within it. If this sub-sub-TLV is included		(Section 6.1) that the router participates in as BFR.
	more than once, the result is unspecified.
	0 1 2 3		On violation of any of the following conditions, the receiving router
	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		SHOULD signal a misconfiguration condition. Further results are
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		unspecified:
	| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		o The sub-sub-TLV MUST be included once AND ONLY once within the
	| Lbl Range Size|Reservd| Label |		sub-TLV.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			o Label ranges within the sub-sub-TLV MUST NOT overlap. A receiving
			BFR MAY additionally check whether any of the ranges in all the
			sub-sub-TLVs advertised by another BFR overlap and apply the same
			treatement on violations.
			o Bitstring lengths within the sub-sub-TLV MUST NOT repeat.
			o The sub-sub-TLV MUST include the required bitstring lengths per
			[I-D.draft-wijnands-bier-architecture-02].
			o All label range sizes MUST be greater than 0.
			o All labels MUST represent valid label values.
			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 | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+
			| Lbl Range Size|BS Len | Label | |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
			~~ (number repetitions derived from TLV length) ~~ ~~~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
			| Lbl Range Size|BS Len | Label | |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+
	Type: value of 0 indicating MPLS encapsulation.		Type: value of 0 indicating MPLS encapsulation.
	Length: 1 octet.		Length: 1 octet.
			Local BitString Length (BS Len): Bitstring length for the label
			range that this router is advertising per
			[I-D.draft-wijnands-mpls-bier-encapsulation-02]. 4 bits.
	Label Range Size: Number of labels in the range used on		Label Range Size: Number of labels in the range used on
	encapsulation for this BIER domain, 1 octet. This MUST never be		encapsulation for this BIER sub-domain for this bitstring length,
	advertise as 0 (zero) and otherwise, this sub-sub-TLV must be		1 octet. This MUST never be advertised as 0 (zero) and otherwise,
	treated as if not present for BFT calculations and a		this sub-sub-TLV must be treated as if not present for BFT
	misconfiguration SHOULD be reported by the receiving router.		calculations and a misconfiguration SHOULD be reported by the
			receiving router.
	Label: First label of the range used on encapsulation for this BIER		Label: First label of the range used on encapsulation for this BIER
	domain and service, 20 bits. The label is used for example by		sub-domain for this bitstring length, 20 bits. The label is used
	[I-D.draft-wijnands-mpls-bier-encapsulation-01] to forward traffic		for example by [I-D.draft-wijnands-mpls-bier-encapsulation-02] to
	to sets of BFERs.		forward traffic to sets of BFERs.
	Reserved reserved, must be 0 on transmission, ignored on reception.		6.3. Optional BIER sub-domain Tree Type sub-sub-TLV
	4 bits
			This sub-sub-TLV carries the information of the BIER tree type for a
			certain <MT,SD>. It is carried within the BIER Info sub-TLV
			(Section 6.1) that the router participates in as BFR. This sub-sub-
			TLV is optional and its absence indicates the same as its presence
			with Tree Type value 0 (SPF). BIER implementation following this
			version of the RFC SHOULD NOT advertise this TLV.
			On violation of any of the following conditions, the receiving router
			implementing this RFC SHOULD signal a misconfiguration condition.
			Further results are unspecified unless described further:
			o The sub-sub-TLV MUST be included once AND ONLY once.
			o The advertised BIER TLV version is 0 and the value of Tree Type
			MUST be 0 (SPF).
			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 | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Tree Type |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Tree Type specific opaque data|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~~ up to TLV Length ~~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Tree Type specific opaque data|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Type: value of 1 indicating BIER Tree Type.
			Length: 1 octet.
			Tree Type: The only supported value today is 0 and indicates that
			BIER uses normal SPF computed reachability to construct BIFT.
			BIER implementation following this RFC MUST ignore the node for
			purposes of the sub-domain <MT,SD> if this field has any value
			except 0.
			Tree type specific opaque data: Opaque data up to the length of the
			TLV carrying tree type specific parameters. For Tree Type 0 (SPF)
			no such data is included and therefore TLV Length is 1.
	7. Security Considerations		7. Security Considerations
	Implementations must assure that malformed TLV and Sub-TLV		Implementations must assure that malformed TLV and Sub-TLV
	permutations do not result in errors which cause hard protocol		permutations do not result in errors which cause hard protocol
	failures.		failures.
	8. Acknowledgements		8. Acknowledgements
	The draft is aligned with the		The RFC is aligned with the [I-D.draft-psenak-ospf-bier-extension-01]
	[I-D.draft-psenak-ospf-bier-extension-01] draft as far as the		draft as far as the protocol mechanisms overlap.
	protocol mechanisms overlap.
	Many thanks for comments from (in no particular order) Hannes		Many thanks for comments from (in no particular order) Hannes
	Gredler, Ijsbrand Wijnands and Peter Psenak.		Gredler, Ijsbrand Wijnands and Peter Psenak.
	9. Normative References		9. Normative References
	[I-D.draft-ginsberg-isis-prefix-attributes]		[I-D.draft-ginsberg-isis-prefix-attributes]
	Ginsberg et al., U., "IS-IS Prefix Attributes for Extended		Ginsberg et al., U., "IS-IS Prefix Attributes for Extended
	IP and IPv6 Reachability", internet-draft draft-ginsberg-		IP and IPv6 Reachability", internet-draft draft-ginsberg-
	isis-prefix-attributes-00.txt, October 2014.		isis-prefix-attributes-00.txt, October 2014.
	[I-D.draft-psenak-ospf-bier-extension-01]		[I-D.draft-psenak-ospf-bier-extension-01]
	Psenak, P. and IJ. Wijnands, "OSPF Extension for Bit Index		Psenak, P. and IJ. Wijnands, "OSPF Extension for Bit Index
	Explicit Replication", internet-draft draft-ietf-ospf-		Explicit Replication", internet-draft draft-ietf-ospf-
	prefix-link-attr-01.txt, October 2014.		prefix-link-attr-01.txt, October 2014.
	[I-D.draft-wijnands-bier-architecture-00]		[I-D.draft-wijnands-bier-architecture-02]
	Wijnands, IJ., "Stateless Multicast using Bit Index		Wijnands, IJ., "Stateless Multicast using Bit Index
	Explicit Replication Architecture", internet-draft draft-		Explicit Replication Architecture", internet-draft draft-
	wijnands-bier-architecture-00.txt, February 2014.		wijnands-bier-architecture-02.txt, February 2014.
	[I-D.draft-wijnands-mpls-bier-encapsulation-01]		[I-D.draft-wijnands-mpls-bier-encapsulation-02]
	Wijnands et al., IJ., "Bit Index Explicit Replication		Wijnands et al., IJ., "Bit Index Explicit Replication
	using MPLS encapsulation", internet-draft draft-wijnands-		using MPLS encapsulation", internet-draft draft-wijnands-
	mpls-bier-encapsulation-01.txt, February 2014.		mpls-bier-encapsulation-02.txt, February 2014.
	[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and		[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
	dual environments", RFC 1195, December 1990.		dual environments", RFC 1195, December 1990.
	[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.
	[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate		[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
	System to Intermediate System (IS-IS) Extensions for		System to Intermediate System (IS-IS) Extensions for
	Advertising Router Information", RFC 4971, July 2007.		Advertising Router Information", RFC 4971, July 2007.
End of changes. 59 change blocks.
	149 lines changed or deleted		291 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/