< draft-ietf-lsr-isis-flood-reflection-01.txt		draft-ietf-lsr-isis-flood-reflection-02.txt >
	Network Working Group A. Przygienda		Network Working Group A. Przygienda
	Internet-Draft C. Bowers		Internet-Draft C. Bowers
	Intended status: Standards Track Juniper		Intended status: Standards Track Juniper
	Expires: January 28, 2021 Y. Lee		Expires: July 22, 2021 Y. Lee
	A. Sharma		A. Sharma
	Comcast		Comcast
	R. White		R. White
	Juniper		Juniper
	July 27, 2020		January 18, 2021
	IS-IS Flood Reflection		IS-IS Flood Reflection
	draft-ietf-lsr-isis-flood-reflection-01		draft-ietf-lsr-isis-flood-reflection-02
	Abstract		Abstract
	This document describes an optional ISIS extension that allows the		This document describes an optional ISIS extension that allows the
	creation of IS-IS flood reflection topologies. Flood reflection		creation of IS-IS flood reflection topologies. Flood reflection
	allows the creation of topologies where L1 areas provide transit		allows the creation of topologies where L1 areas provide transit
	forwarding for L2 destinations within an L2 topology. It		forwarding for L2 destinations within an L2 topology. It
	accomplishes this by creating L2 flood reflection adjacencies within		accomplishes this by creating L2 flood reflection adjacencies within
	each L1 area. The L2 flood reflection adjacencies are used to flood		each L1 area. The L2 flood reflection adjacencies are used to flood
	L2 LSPDUs, and they are used in the L2 SPF computation. However,		L2 LSPDUs, and they are used in the L2 SPF computation. However,
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 January 28, 2021.		This Internet-Draft will expire on July 22, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	skipping to change at page 9, line 47 ¶		skipping to change at page 9, line 47 ¶
	RESERVED: This field is reserved for future use. It MUST be set to		RESERVED: This field is reserved for future use. It MUST be set to
	0 when sent and MUST be ignored when received.		0 when sent and MUST be ignored when received.
	Flood Reflection Cluster ID: Flood Reflection Cluster Identifier.		Flood Reflection Cluster ID: Flood Reflection Cluster Identifier.
	These same 32-bit value MUST be assigned to all of the flood		These same 32-bit value MUST be assigned to all of the flood
	reflectors and flood reflector clients in the L1 area. The value		reflectors and flood reflector clients in the L1 area. The value
	MUST be unique across different L1 areas within the IGP domain.		MUST be unique across different L1 areas within the IGP domain.
	On a given router, the same value of the Flood Reflection Cluster		On a given router, the same value of the Flood Reflection Cluster
	ID MUST be advertised across all interfaces advertising the Flood		ID MUST be advertised across all interfaces advertising the Flood
	Reflection TLV in IIHs.		Reflection TLV in IIHs. This implies that a flood reflector can
			participate in a single L1 area only.
	Sub-TLVs: Optional sub-TLVs. For future extensibility, the format		Sub-TLVs: Optional sub-TLVs. For future extensibility, the format
	of the Flood Reflection TLV allows for the possibility of		of the Flood Reflection TLV allows for the possibility of
	including optional sub-TLVs. No sub-TLVs of the Flood Reflection		including optional sub-TLVs. No sub-TLVs of the Flood Reflection
	TLV are defined in this document.		TLV are defined in this document.
	The Flood Reflection TLV MUST NOT appear more than once in an IIH. A		The Flood Reflection TLV MUST NOT appear more than once in an IIH. A
	router receiving multiple Flood Reflection TLVs in the same IIH		router receiving multiple Flood Reflection TLVs in the same IIH
	SHOULD use the values in the first TLV.		SHOULD use the values in the first TLV.
	skipping to change at page 12, line 39 ¶		skipping to change at page 12, line 39 ¶
	7. Flood Reflection Adjacency Formation		7. Flood Reflection Adjacency Formation
	In order to simplify both implementations and network deployments, we		In order to simplify both implementations and network deployments, we
	do not allow the formation of complex hierarchies of flood reflectors		do not allow the formation of complex hierarchies of flood reflectors
	and clients. All flood reflectors and flood reflector clients in the		and clients. All flood reflectors and flood reflector clients in the
	same L1 area MUST share the same Flood Reflector Cluster ID. A flood		same L1 area MUST share the same Flood Reflector Cluster ID. A flood
	reflector MUST only form flood reflection adjacencies with flood		reflector MUST only form flood reflection adjacencies with flood
	reflector clients. A flood reflector MUST NOT form any traditional		reflector clients. A flood reflector MUST NOT form any traditional
	L2 adjacencies. Flood reflector clients MUST only form flood		L2 adjacencies. Flood reflector clients MUST only form flood
	reflection adjacencies with flood reflectors. Flood reflector		reflection adjacencies with flood reflectors. Flood reflector
	clients may form traditional L2 adjacencies with flood reflector		clients MAY form traditional L2 adjacencies with flood reflector
	clients or nodes not participating in flood reflection.		clients or nodes not participating in flood reflection.
	The Flood Reflector Cluster ID and flood reflector roles advertised		The Flood Reflector Cluster ID and flood reflector roles advertised
	in the Flood Reflection TLVs in IIHs are used to ensure that flood		in the Flood Reflection TLVs in IIHs are used to ensure that flood
	reflection adjacencies that are established meet the above criteria.		reflection adjacencies that are established meet the above criteria.
	Once a flood reflection adjacency is established, the flood reflector		Once a flood reflection adjacency is established, the flood reflector
	and the flood reflector client MUST advertise the adjacency by		and the flood reflector client MUST advertise the adjacency by
	including the Flood Reflection Adjacency Sub-TLV in the Extended IS		including the Flood Reflection Adjacency Sub-TLV in the Extended IS
	reachability TLV or MT-ISN TLV.		reachability TLV or MT-ISN TLV.
	skipping to change at page 14, line 24 ¶		skipping to change at page 14, line 24 ¶
	A flood reflector with directly L2 attached prefixes should advertise		A flood reflector with directly L2 attached prefixes should advertise
	those in L1 as well since based on preference of L1 routes the		those in L1 as well since based on preference of L1 routes the
	clients will not try to use the L2 flood reflector adjacency to route		clients will not try to use the L2 flood reflector adjacency to route
	the packet towards them. A very, very corner case is when the flood		the packet towards them. A very, very corner case is when the flood
	reflector is reachable via L2 flood reflector adjacency (due to		reflector is reachable via L2 flood reflector adjacency (due to
	underlying L1 partition) only in which case the client can use the L2		underlying L1 partition) only in which case the client can use the L2
	tunnel to the flood reflector for forwarding towards those prefixes		tunnel to the flood reflector for forwarding towards those prefixes
	while it MUST initiate an alarm and declare misconfiguration.		while it MUST initiate an alarm and declare misconfiguration.
			A flood reflector SHOULD NOT set the attached bit on its LSPs.
	Instead of modifying the computation procedures one could imagine a		Instead of modifying the computation procedures one could imagine a
	flood reflector solution where the Flood Reflector would re-advertise		flood reflector solution where the Flood Reflector would re-advertise
	the L2 prefixes with a 'third-party' next-hop but that would have		the L2 prefixes with a 'third-party' next-hop but that would have
	less desirable convergence properties than the solution proposed and		less desirable convergence properties than the solution proposed and
	force a fork-lift of all L2 routers to make sure they disregard such		force a fork-lift of all L2 routers to make sure they disregard such
	prefixes unless in the same L1 domain as the Flood Reflector.		prefixes unless in the same L1 domain as the Flood Reflector.
	Depending on pseudo-node choice in case of a broadcast domain with		Depending on pseudo-node choice in case of a broadcast domain with
	multiple flood reflectors attached this can lead to a partitioned LAN		multiple flood reflectors attached this can lead to a partitioned LAN
	and hence a router discovering such a condition MUST initiate an		and hence a router discovering such a condition MUST initiate an
End of changes. 8 change blocks.
	7 lines changed or deleted		10 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/