< draft-ietf-bier-isis-extensions-00.txt		draft-ietf-bier-isis-extensions-01.txt >
	Internet Engineering Task Force L. Ginsberg, Ed.		Internet Engineering Task Force L. Ginsberg, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track A. Przygienda		Intended status: Standards Track A. Przygienda
	Expires: October 29, 2015 Ericsson		Expires: April 19, 2016 Ericsson
	S. Aldrin		S. Aldrin
	Google		Google
	J. Zhang		J. Zhang
	Juniper Networks, Inc.		Juniper Networks, Inc.
	April 27, 2015		October 17, 2015
	BIER support via ISIS		BIER support via ISIS
	draft-ietf-bier-isis-extensions-00		draft-ietf-bier-isis-extensions-01
	Abstract		Abstract
	Specification of an ISIS extension to support BIER domains and sub-		Specification of an ISIS extension to support BIER domains and sub-
	domains.		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
	skipping to change at page 1, line 42 ¶		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 October 29, 2015.		This Internet-Draft will expire on April 19, 2016.
	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 36 ¶		skipping to change at page 2, line 36 ¶
	5.4. Tree Type . . . . . . . . . . . . . . . . . . . . . . . . 5		5.4. Tree Type . . . . . . . . . . . . . . . . . . . . . . . . 5
	5.5. Label Advertisements for MPLS encapsulated BIER sub-		5.5. Label Advertisements for MPLS encapsulated BIER sub-
	domains . . . . . . . . . . . . . . . . . . . . . . . . . 5		domains . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5.5.1. Special Consideration . . . . . . . . . . . . . . . . 6		5.5.1. Special Consideration . . . . . . . . . . . . . . . . 6
	5.6. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 6		5.6. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 6
	5.7. Flooding . . . . . . . . . . . . . . . . . . . . . . . . 6		5.7. Flooding . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 6		6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. BIER Info sub-TLV . . . . . . . . . . . . . . . . . . . . 7		6.1. BIER Info sub-TLV . . . . . . . . . . . . . . . . . . . . 7
	6.2. BIER MPLS Encapsulation sub-sub-TLV . . . . . . . . . . . 8		6.2. BIER MPLS Encapsulation sub-sub-TLV . . . . . . . . . . . 8
	6.3. Optional BIER sub-domain Tree Type sub-sub-TLV . . . . . 9		6.3. Optional BIER sub-domain Tree Type sub-sub-TLV . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6.4. Optional BIER sub-domain BSL conversion sub-sub-TLV . . . 10
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
			8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	9. Normative References . . . . . . . . . . . . . . . . . . . . 11		9. Normative References . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Bit Index Explicit Replication (BIER)		Bit Index Explicit Replication (BIER)
	[I-D.draft-ietf-bier-architecture-00] defines an architecture where		[I-D.draft-ietf-bier-architecture-02] defines an architecture where
	all intended multicast receivers are encoded as bitmask in the		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-02]. A router that		[I-D.draft-ietf-bier-mpls-encapsulation-02]. A router that receives
	receives such a packet will forward the packet based on the Bit		such a packet will forward the packet based on the Bit Position in
	Position in the packet header towards the receiver(s), following a		the packet header towards the receiver(s), following a precomputed
	precomputed tree for each of the bits in the packet. Each receiver		tree for each of the bits in the packet. Each receiver is
	is represented by a unique bit in the bitmask.		represented by a unique bit in the bitmask.
	This document presents necessary extensions to the currently deployed		This document presents necessary extensions to the currently deployed
	ISIS for IP [RFC1195] protocol to support distribution of information		ISIS for IP [RFC1195] protocol to support distribution of information
	necessary for operation of BIER domains and sub-domains. This		necessary for operation of BIER domains and sub-domains. 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 BIER signaling.		participating in BIER signaling.
	2. Terminology		2. Terminology
	Some of the terminology specified in		Some of the terminology specified in
	[I-D.draft-ietf-bier-architecture-00] is replicated here and extended		[I-D.draft-ietf-bier-architecture-02] is replicated here and extended
	by necessary definitions:		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).
	BFR: Bit Forwarding Router (A router that participates in Bit Index		BFR: Bit Forwarding Router (A router that participates in Bit Index
	Multipoint Forwarding). A BFR is identified by a unique BFR-		Multipoint Forwarding). A BFR is identified by a unique BFR-
	skipping to change at page 4, line 44 ¶		skipping to change at page 4, line 44 ¶
	Each BIER sub-domain has as its unique attributes the encapsulation		Each BIER sub-domain has as its unique attributes the encapsulation
	used and the type of tree it is using to forward BIER frames		used and the type of tree it is using to forward BIER frames
	(currently always SPF). Additionally, per supported bitstring length		(currently always SPF). Additionally, per supported bitstring length
	in the sub-domain, each router will advertise the necessary label		in the sub-domain, each router will advertise the necessary label
	ranges to support it.		ranges to support it.
	This RFC introduces a sub-TLV in the extended reachability TLVs to		This RFC introduces a sub-TLV in the extended reachability TLVs to
	distribute such information about BIER sub-domains. To satisfy the		distribute such information about BIER sub-domains. To satisfy the
	requirements for BIER prefixes per		requirements for BIER prefixes per
	[I-D.draft-ietf-bier-architecture-00] additional information will be		[I-D.draft-ietf-bier-architecture-02] additional information will be
	carried in [I-D.draft-ginsberg-isis-prefix-attributes].		carried in [I-D.draft-ietf-isis-prefix-attributes-01].
	5. Procedures		5. Procedures
	5.1. Enabling a BIER Sub-Domain		5.1. Enabling a BIER Sub-Domain
	A given sub-domain with identifier SD with supported bitstring		A given sub-domain with identifier SD with supported bitstring
	lengths MLs in a multi-topology MT [RFC5120] is denoted further as		lengths MLs in a multi-topology MT [RFC5120] is denoted further as
	<MT,SD,MLs> and dos not have to be advertised by by default by BFRs		<MT,SD,MLs> and dos not have to be advertised by by default by BFRs
	to preserve the scaling of the protocol (i.e. ISIS carries no TLVs		to preserve the scaling of the protocol (i.e. ISIS carries no TLVs
	containing any of the elements related to <MT,SD>). The		containing any of the elements related to <MT,SD>). The
	advertisement may be triggered e.g. by a first BIER sub-TLV		advertisement may be triggered e.g. by a first BIER sub-TLV
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 4 ¶
	same tree type for a given <MT,SD>. In case of mismatch the behavior		same tree type for a given <MT,SD>. In case of mismatch the behavior
	is analogous to Section 5.3.		is analogous to Section 5.3.
	5.5. Label Advertisements for MPLS encapsulated BIER sub-domains		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,SD>		TLV (Section 6.2) of a BIER Info sub-TLV (Section 6.1) for <MT,SD>
	(denoted as TLV<MT,SD>) for every supported bitstring length a valid		(denoted as TLV<MT,SD>) for every supported bitstring length a valid
	starting label value and a non-zero range length. It MUST advertise		starting label value and a non-zero range length. It MUST advertise
	at least one valid label value and a non-zero range length for the		at least one valid label value and a non-zero range length for the
	required bitstring lengths per [I-D.draft-ietf-bier-architecture-00]		required bitstring lengths per [I-D.draft-ietf-bier-architecture-02]
	in case it has computed itself as being on the BFT rooted at any of		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		the BFRs with valid BFR-ids (except itself if it does NOT have a
	valid BFR-id) participating in <MT,SD>.		valid BFR-id) participating in <MT,SD>.
	A router MAY decide to not advertise the BIER Info sub-TLV		A router MAY decide to not advertise the BIER Info sub-TLV
	(Section 6.1) for <MT,SD> if it does not want to participate in the		(Section 6.1) for <MT,SD> if it does not want to participate in the
	sub-domain due to resource constraints, label space optimization,		sub-domain due to resource constraints, label space optimization,
	administrative configuration or any other reasons.		administrative configuration or any other reasons.
	5.5.1. Special Consideration		5.5.1. Special Consideration
	A router that desires to participate in <MT,SD> MUST advertise for		A router that desires to participate in <MT,SD> MUST advertise for
	each bitstring length it supports in <MT,SD> a label range size that		each bitstring length it supports in <MT,SD> a label range size that
	guarantees to cover the maximum BFR-id injected into <MT,SD> (which		guarantees to cover the maximum BFR-id injected into <MT,SD> (which
	implies a certain maximum set id per bitstring length as described in		implies a certain maximum set id per bitstring length as described in
	[I-D.draft-ietf-bier-architecture-00]). Any router that violates		[I-D.draft-ietf-bier-architecture-02]). Any router that violates
	this condition MUST be excluded from BIER BFTs for <MT,SD>.		this condition MUST be excluded from BIER BFTs for <MT,SD>.
	5.6. BFR-id Advertisements		5.6. BFR-id Advertisements
	Each BFER MAY advertise with its TLV<MT,SD> 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,SD>, 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,SD> to align with [I-D.draft-ietf-bier-architecture-00]. It is		<MT,SD> to align with [I-D.draft-ietf-bier-architecture-02]. It is
	worth observing that based on this procedure routers with colliding		worth observing that based on this procedure routers with colliding
	BFR-id assignments in <MT,SD> MAY still act as BFIRs in <MT,SD> but		BFR-id assignments in <MT,SD> MAY still act as BFIRs in <MT,SD> but
	will be never able to receive traffic from other BFRs in <MT,SD>.		will be never able to receive traffic from other BFRs in <MT,SD>.
	5.7. Flooding		5.7. Flooding
	BIER domain information SHOULD change and force flooding		BIER domain information SHOULD change and force flooding
	infrequently. Especially, the router SHOULD make every possible		infrequently. Especially, the router SHOULD make every possible
	attempt to bundle all the changes necessary to sub-domains and ranges		attempt to bundle all the changes necessary to sub-domains and ranges
	advertised with those into least possible updates.		advertised with those into least possible updates.
	skipping to change at page 7, line 41 ¶		skipping to change at page 7, line 41 ¶
	Type: as indicated in IANA section.		Type: as indicated in IANA section.
	Length: 1 octet.		Length: 1 octet.
	Reserved: reserved, must be 0 on transmission, ignored on reception.		Reserved: reserved, must be 0 on transmission, ignored on reception.
	May be used in future versions. 8 bits		May be used in future versions. 8 bits
	subdomain-id: Unique value identifying the BIER sub-domain. 1 octet		subdomain-id: Unique value identifying the BIER sub-domain. 1 octet
	BFR-id: A 2 octet field encoding the BFR-id, as documented in		BFR-id: A 2 octet field encoding the BFR-id, as documented in
	[I-D.draft-ietf-bier-architecture-00]. If set to the invalid BFR-		[I-D.draft-ietf-bier-architecture-02]. If set to the invalid BFR-
	id advertising router is not owning a BFR-id in the sub-domain.		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
	encapsulation and the necessary label ranges per bitstring length for		encapsulation and the necessary label ranges per bitstring length for
	a certain <MT,SD> and is carried within the BIER Info sub-TLV		a certain <MT,SD> and is carried within the BIER Info sub-TLV
	(Section 6.1) that the router participates in as BFR.		(Section 6.1) that the router participates in as BFR.
	On violation of any of the following conditions, the receiving router		On violation of any of the following conditions, the receiving router
	skipping to change at page 8, line 31 ¶		skipping to change at page 8, line 31 ¶
	the whole sub-sub-TLV MUST be disregarded and the violating		the whole sub-sub-TLV MUST be disregarded and the violating
	routers are treated per further procedures in Section 5.3.		routers are treated per further procedures in Section 5.3.
	o Bitstring lengths within the sub-sub-TLV MUST NOT repeat,		o Bitstring lengths within the sub-sub-TLV MUST NOT repeat,
	otherwise the whole sub-sub-TLV MUST be disregarded and the		otherwise the whole sub-sub-TLV MUST be disregarded and the
	violating routers are treated per further procedures in		violating routers are treated per further procedures in
	Section 5.3.		Section 5.3.
	o The sub-sub-TLV MUST include the required bitstring lengths		o The sub-sub-TLV MUST include the required bitstring lengths
	encoded in precisely the same way as in		encoded in precisely the same way as in
	[I-D.draft-ietf-bier-architecture-00].		[I-D.draft-ietf-bier-architecture-02].
	o All label range sizes MUST be greater than 0.		o All label range sizes MUST be greater than 0.
	o All labels MUST represent valid label values, otherwise the whole		o All labels MUST represent valid label values, otherwise the whole
	sub-sub-TLV MUST be disregarded and the violating routers are		sub-sub-TLV MUST be disregarded and the violating routers are
	treated per further procedures in Section 5.3.		treated per further procedures in Section 5.3.
	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 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Lbl Range Size|BS Len | Label | |		| Lbl Range Size|BS Len | Label |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~~ (number repetitions derived from TLV length) ~~ ~~~		~~ (number repetitions derived from TLV length) ~~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Lbl Range Size|BS Len | Label | |		| 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		Local BitString Length (BS Len): Bitstring length for the label
	range that this router is advertising per		range that this router is advertising per
	[I-D.draft-wijnands-mpls-bier-encapsulation-02]. 4 bits.		[I-D.draft-ietf-bier-mpls-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 sub-domain for this bitstring length,		encapsulation for this BIER sub-domain for this bitstring length,
	1 octet. This MUST never be advertised as 0 (zero) and otherwise,		1 octet. This MUST never be advertised as 0 (zero) and otherwise,
	this sub-sub-TLV must be treated as if not present for BFT		this sub-sub-TLV must be treated as if not present for BFT
	calculations and a misconfiguration SHOULD be reported by the		calculations and a misconfiguration SHOULD be reported by the
	receiving router.		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
	sub-domain for this bitstring length, 20 bits. The label is used		sub-domain for this bitstring length, 20 bits. The label is used
	for example by [I-D.draft-wijnands-mpls-bier-encapsulation-02] to		for example by [I-D.draft-ietf-bier-mpls-encapsulation-02] to
	forward traffic to sets of BFERs.		forward traffic to sets of BFERs.
	6.3. Optional BIER sub-domain Tree Type sub-sub-TLV		6.3. Optional BIER sub-domain Tree Type sub-sub-TLV
	This sub-sub-TLV carries the information of the BIER tree type for a		This sub-sub-TLV carries the information of the BIER tree type for a
	<MT,SD> combination. It is carried within the BIER Info sub-TLV		<MT,SD> combination. It is carried within the BIER Info sub-TLV
	(Section 6.1) that the router participates in as BFR. This sub-sub-		(Section 6.1) that the router participates in as BFR. This sub-sub-
	TLV is optional and its absence has the same semantics as its		TLV is optional and its absence has the same semantics as its
	presence with Tree Type value 0 (SPF). BIER implementation following		presence with Tree Type value 0 (SPF). BIER implementation following
	this version of the RFC SHOULD NOT advertise this TLV.		this version of the RFC SHOULD NOT advertise this TLV.
	On violation of any of the following conditions, the receiving router		On violation of any of the following conditions, the receiving router
	implementing this RFC SHOULD signal a misconfiguration condition.		implementing this RFC SHOULD signal a misconfiguration condition.
	Further results are unspecified unless described further:		Further results are unspecified unless described further:
	o The sub-sub-TLV CAN be included AT MOST once.		o The sub-sub-TLV MUST NOT be included more than once.
	o The advertised BIER TLV version is 0 and the value of Tree Type		o The Tree Type MUST be 0 (SPF).
	MUST be 0 (SPF).
	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 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Tree Type |		| Tree Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Tree Type specific opaque data|		| Tree Type specific opaque data|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 10, line 38 ¶		skipping to change at page 10, line 37 ¶
	Tree Type: The only supported value in this specification is 0 and		Tree Type: The only supported value in this specification is 0 and
	indicates that BIER uses normal SPF computed reachability to		indicates that BIER uses normal SPF computed reachability to
	construct BIFT. BIER implementation following this RFC MUST		construct BIFT. BIER implementation following this RFC MUST
	ignore the node for purposes of the sub-domain <MT,SD> if this		ignore the node for purposes of the sub-domain <MT,SD> if this
	field has any value except 0.		field has any value except 0.
	Tree type specific opaque data: Opaque data up to the length of the		Tree type specific opaque data: Opaque data up to the length of the
	TLV carrying tree type specific parameters. For Tree Type 0 (SPF)		TLV carrying tree type specific parameters. For Tree Type 0 (SPF)
	no such data is included and therefore TLV Length is 1.		no such data is included and therefore TLV Length is 1.
			6.4. Optional BIER sub-domain BSL conversion sub-sub-TLV
			This sub-sub-TLV indicates whether the BFR is capable of imposing a
			different Bit String Length (BSL) than the one it received in a BIER
			encapsulated packet. Such a capability may allow future, advanced
			tree types which ensure simple migration procedures from one BSL to
			another in a given <MT,SD> or prevent stable blackholes in scenarios
			where not all routers support the same set of BSLs in a given
			<MT,SD>. It is carried within the BIER Info sub-TLV (Section 6.1).
			This sub-sub-TLV is optional and its absence indicates that the
			router is NOT capable of imposing different BSLs but will always
			forward the packet with the BSL unchanged.
			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 NOT be included more than once.
			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 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Type: value of 2 indicating BIER BSL conversion.
			Length: 1 octet.
	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 RFC is aligned with the		The RFC is aligned with the
	[I-D.draft-ietf-bier-ospf-bier-extensions-00] draft as far as the		[I-D.draft-ietf-bier-ospf-bier-extensions-00] 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, Peter Psenak and Chris Bowers.		Gredler, Ijsbrand Wijnands, Peter Psenak and Chris Bowers.
	9. Normative References		9. Normative References
	[I-D.draft-ginsberg-isis-prefix-attributes]		[I-D.draft-ietf-bier-architecture-02]
	Ginsberg et al., U., "IS-IS Prefix Attributes for Extended		Wijnands et al., IJ., "Stateless Multicast using Bit Index
	IP and IPv6 Reachability", internet-draft draft-ginsberg-
	isis-prefix-attributes-01.txt, October 2014.
	[I-D.draft-ietf-bier-architecture-00]
	Wijnands, IJ., "Stateless Multicast using Bit Index
	Explicit Replication Architecture", internet-draft draft-		Explicit Replication Architecture", internet-draft draft-
	ietf-bier-architecture-00.txt, April 2015.		ietf-bier-architecture-02.txt, July 2015.
			[I-D.draft-ietf-bier-mpls-encapsulation-02]
			Wijnands et al., IJ., "Bit Index Explicit Replication
			using MPLS encapsulation", internet-draft draft-ietf-bier-
			mpls-encapsulation-02.txt, Aug 2015.
	[I-D.draft-ietf-bier-ospf-bier-extensions-00]		[I-D.draft-ietf-bier-ospf-bier-extensions-00]
	Psenak, P. and IJ. Wijnands, "OSPF Extension for Bit Index		Psenak et al., P., "OSPF Extension for Bit Index Explicit
	Explicit Replication", internet-draft draft-ietf-ospf-		Replication", internet-draft draft-ietf-bier-ospf-bier-
	prefix-link-attr-01.txt, April 2015.		extensions-00.txt, October 2014.
	[I-D.draft-wijnands-mpls-bier-encapsulation-02]		[I-D.draft-ietf-isis-prefix-attributes-01]
	Wijnands et al., IJ., "Bit Index Explicit Replication		Ginsberg et al., U., "IS-IS Prefix Attributes for Extended
	using MPLS encapsulation", internet-draft draft-wijnands-		IP and IPv6 Reachability", internet-draft draft-ietf-isis-
	mpls-bier-encapsulation-02.txt, February 2014.		prefix-attributes-01.txt, June 2015.
	[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, DOI 10.17487/RFC1195,
			December 1990, <http://www.rfc-editor.org/info/rfc1195>.
	[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,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi		[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
	Topology (MT) Routing in Intermediate System to		Topology (MT) Routing in Intermediate System to
	Intermediate Systems (IS-ISs)", RFC 5120, February 2008.		Intermediate Systems (IS-ISs)", RFC 5120,
			DOI 10.17487/RFC5120, February 2008,
			<http://www.rfc-editor.org/info/rfc5120>.
	[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic		[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
	Engineering", RFC 5305, October 2008.		Engineering", RFC 5305, DOI 10.17487/RFC5305, October
			2008, <http://www.rfc-editor.org/info/rfc5305>.
	[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October		[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
	2008.		DOI 10.17487/RFC5308, October 2008,
			<http://www.rfc-editor.org/info/rfc5308>.
	[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP		[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
	VPNs", RFC 6513, February 2012.		BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
			2012, <http://www.rfc-editor.org/info/rfc6513>.
	Authors' Addresses		Authors' Addresses
	Les Ginsberg (editor)		Les Ginsberg (editor)
	Cisco Systems		Cisco Systems
	510 McCarthy Blvd.		510 McCarthy Blvd.
	Milpitas, CA 95035		Milpitas, CA 95035
	USA		USA
	Email: ginsberg@cisco.com		Email: ginsberg@cisco.com
End of changes. 30 change blocks.
	59 lines changed or deleted		96 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/