< draft-ietf-isis-wg-multi-topology-11.txt		draft-ietf-isis-wg-multi-topology-12.txt >
	Network Working Group Tony Przygienda		Internet Draft Tony Przygienda
	Internet Draft Naiming Shen (Cisco)		prz@net4u.ch
	<draft-ietf-isis-wg-multi-topology-11.txt> Nischal Sheth (Juniper)		Naiming Shen
	October 2005		Cisco Systems
	Expires: April 2006		Nischal Sheth
			Juniper Networks
			Expires: May 2008 November 5, 2007
			Intended Status: Proposed Standard
	M-ISIS: Multi Topology (MT) Routing in IS-IS		M-ISIS: Multi Topology (MT) Routing in IS-IS
			<draft-ietf-isis-wg-multi-topology-12.txt>
	Status of This Memo		Status of This Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six months
	months and may be updated, replaced, or obsoleted by other		and may be updated, replaced, or obsoleted by other documents at any
	documents at any time. It is inappropriate to use Internet-Drafts		time. It is inappropriate to use Internet-Drafts as reference
	as reference material or to cite them other than as "work in		material or to cite them other than as "work in progress."
	progress".
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
			Copyright Notice
			Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This draft describes an optional mechanism within ISIS used today		This document describes an optional mechanism within ISIS used today
	by many ISPs for IGP routing within their clouds. This draft		by many ISPs for IGP routing within their clouds. This document
	describes how to run within a single ISIS domain a set of		describes how to run within a single ISIS domain a set of
	independent IP topologies that we call Multi-Topologies (MTs).		independent IP topologies that we call Multi-Topologies (MTs).
	This MT extension can be used for variety of purposes such as an		This MT extension can be used for variety of purposes such as an
	in-band management network ``on top'' of the original IGP topology,		in-band management network ``on top'' of the original IGP topology,
	maintain separate IGP routing domains for isolated multicast or		maintain separate IGP routing domains for isolated multicast or
	IPv6 islands within the backbone, or force a subset of an address		IPv6 islands within the backbone, or force a subset of an address
	space to follow a different topology.		space to follow a different topology.
	Specification of Requirements
	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].
	1. Introduction		1. Introduction
	Maintaining multiple MTs for ISIS [ISO10589 , RFC1195] in a		Maintaining multiple MTs for ISIS [ISO10589] [RFC1195] in a
	backwards-compatible manner necessitates several extensions to the		backwards-compatible manner necessitates several extensions to the
	packet encoding and additional SPF procedures. The problem can		packet encoding and additional SPF procedures. The problem can
	be partitioned into forming of adjacencies, and advertising of		be partitioned into forming of adjacencies, and advertising of
	prefixes and reachable intermediate systems within each topology.		prefixes and reachable intermediate systems within each topology.
	Having put all the necessary additional information in place, it		Having put all the necessary additional information in place, it
	must be properly used by MT capable SPF computation. The following		must be properly used by MT capable SPF computation. The following
	sections describe each of the problems separately. To simplify the		sections describe each of the problems separately. To simplify the
	text, ``standard'' ISIS topology is defined to be MT ID #0 (zero).		text, "standard" ISIS topology is defined to be MT ID #0 (zero).
			1.1 Conventions Used in This Document
			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].
			1.2 Definitions of Terms Used in This Document
			CSNP Complete Sequence Number Packet. Used to describe all the
			contents of a link state database of IS-IS.
			DIS Designated Intermediate System. The intermediate system
			elected to advertise the pseudonode for a broadcast
			network.
			IIH IS-IS Hello. Packets that are used to discover adjacent
			intermediate systems.
			LSP Link State Packet. Packet generated by an intermediate
			system and lists adjacent systems, prefixes and other
			information.
			PSNP Partial Sequence Number Packet. Used to request information
			from an adjacent intermediate system's link state
			database.
			SPF Shortest Path First. An algorithm that takes a database
			of nodes within a domain and builds a tree of connectivity
			along the shortest paths through the entire network.
	2. Maintaining MT Adjacencies		2. Maintaining MT Adjacencies
	Each adjacency formed MUST be classified as belonging to a set of		Each adjacency formed MUST be classified as belonging to a set of
	MTs on the interface. This is achieved by adding a new TLV into		MTs on the interface. This is achieved by adding a new TLV into
	IIH packets that advertises which topologies the interface belongs		IIH packets that advertises which topologies the interface belongs
	to. If MT #0 is the only MT on the interface, it is optional to		to. If MT #0 is the only MT on the interface, it is optional to
	advertise it in the new TLV. Thus not including such a TLV in the		advertise it in the new TLV. Thus not including such a TLV in the
	IIH implies MT ID #0 capability only. Through this exchange of MT		IIH implies MT ID #0 capability only. Through this exchange of MT
	capabilities, a router is able to advertise the IS TLVs in LSPs		capabilities, a router is able to advertise the IS TLVs in LSPs
	with common MT set over those adjacencies.		with common MT set over those adjacencies.
	In the case of adjacency contains multiple MTs on an interface, and		In the case of adjacency contains multiple MTs on an interface, and
	if there exists overlapping IP address space among the topologies,		if there exists overlapping IP address space among the topologies,
	additional mechanism MAY be used to resolve the topology identity of		additional mechanism MUST be used to resolve the topology identity
	the incoming IP packets on the interface.		of the incoming IP packets on the interface. See more discussion in
			section 8.2.2 of this document.
	2.1. Forming Adjacencies on Point-to-Point Interfaces		2.1. Forming Adjacencies on Point-to-Point Interfaces
	Adjacencies on point-to-point interfaces are formed as usual with		Adjacencies on point-to-point interfaces are formed as usual with
	ISIS routers not implementing MT extensions. If local router does		ISIS routers not implementing MT extensions. If local router does
	not participate in certain MTs, it will not advertise those MTIDs		not participate in certain MTs, it will not advertise those MTIDs
	in its IIHs and thus will not include that neighbor within it's		in its IIHs and thus will not include that neighbor within it's
	LSPs. On the other hand, if a MTID is not detected in remote		LSPs. On the other hand, if a MTID is not detected in remote
	side's IIHs, the local router MUST NOT include that neighbor		side's IIHs, the local router MUST NOT include that neighbor
	within its LSPs. The local router SHOULD NOT form an adjacency if		within its LSPs. The local router SHOULD NOT form an adjacency if
	skipping to change at page 3, line 39 ¶		skipping to change at page 4, line 18 ¶
	special TLVs in the pseudo-node LSPs nor run distinct DIS elections		special TLVs in the pseudo-node LSPs nor run distinct DIS elections
	per MT. Therefore, a generated pseudo-node LSP by DIS MUST contain		per MT. Therefore, a generated pseudo-node LSP by DIS MUST contain
	in its IS Reachable TLV all nodes on the LAN as usual regardless		in its IS Reachable TLV all nodes on the LAN as usual regardless
	of their MT capabilities. In other words, there is no change to the		of their MT capabilities. In other words, there is no change to the
	pseudo-node LSP construction.		pseudo-node LSP construction.
	4. MTs and Overload, Partition and Attached Bits		4. MTs and Overload, Partition and Attached Bits
	A router could for each of the MTs become potentially		A router could for each of the MTs become potentially
	partitioned, overloaded and attached independently. To prevent		partitioned, overloaded and attached independently. To prevent
	unnecessary complexity, MT extensions does not support		unnecessary complexity, MT extensions does not support MT based
	partition repair. The overload, partition and attached bits in LSP		partition repair. The overload, partition and attached bits in LSP
	header only reflect the status of the default topology.		header only reflect the status of the default topology.
	Attached bit and overload bit are part of the MT TLV being		Attached bit and overload bit are part of the MT TLV being
	distributed within a node's LSP fragment zero. Since each adjacency		distributed within a node's LSP fragment zero. Since each adjacency
	can belong to different MTs, it is possible that some MTs are L2		can belong to different MTs, it is possible that some MTs are L2
	attached, and others are not on the same router. The overload		attached, and others are not on the same router. The overload
	bit in the MT TLV can be used to signal the topology being		bit in the MT TLV can be used to signal the topology being
	overloaded. A MT based system is considered being overloaded if		overloaded. A MT based system is considered being overloaded if
	the overload bit in the MT is set.		the overload bit in the MT is set.
	skipping to change at page 4, line 34 ¶		skipping to change at page 5, line 13 ¶
	in normal cases, otherwise overlapping addresses in different		in normal cases, otherwise overlapping addresses in different
	topologies could lead to undesirable routing behavior such as		topologies could lead to undesirable routing behavior such as
	forwarding loops. The forwarding logic and configuration need to		forwarding loops. The forwarding logic and configuration need to
	ensure the same MT is traversed from the source to the destination		ensure the same MT is traversed from the source to the destination
	for packets. The nexthops derived from the MT SPF MUST belong to		for packets. The nexthops derived from the MT SPF MUST belong to
	the adjacencies conforming to the same MT for correct forwarding.		the adjacencies conforming to the same MT for correct forwarding.
	It is recommended for the administrators to ensure consistent		It is recommended for the administrators to ensure consistent
	configuration of all routers in the domain to prevent undesirable		configuration of all routers in the domain to prevent undesirable
	forwarding behavior.		forwarding behavior.
	No attempt is made in this draft to allow one topology to calculate		No attempt is made in this document to allow one topology to
	routes using the routing information from another topology inside		calculate routes using the routing information from another
	SPF. Even though it is possible to redistribute and leak routes		topology inside SPF. Even though it is possible to redistribute
	from another IS-IS topology or from external sources, and the		and leak routes from another IS-IS topology or from external
	exact mechanism is beyond the scope of this document.		sources, and the exact mechanism is beyond the scope of this
			document.
	7. Packet Encoding		7. Packet Encoding
	Three new TLVs are added to support MT extensions. One of them is		Three new TLVs are added to support MT extensions. One of them is
	common for the LSPs and IIHs. Encoding of Intermediate System TLV		common for the LSPs and IIHs. Encoding of Intermediate System TLV
	and IPv4 Reachable Prefixes is tied to traffic engineering		and IPv4 Reachable Prefixes is tied to traffic engineering
	extensions [LS01] to simplify the implementation effort. The main		extensions [LS01] to simplify the implementation effort. The main
	reasons we choose using new TLVs instead of using sub-TLVs inside		reasons we choose using new TLVs instead of using sub-TLVs inside
	existing TLV type-22 and type-135 are: In many cases,		existing TLV type-22 and type-135 are: In many cases,
	multi-topologies are non-congruent, using sub-TLV approach will		multi-topologies are non-congruent, using sub-TLV approach will
	not save LSP space; Many sub-TLVs are already being used in TLV		not save LSP space; Many sub-TLVs are already being used in TLV
	type-22, and many more are being proposed while there is a maximum		type-22, and many more are being proposed while there is a maximum
	limit on the TLV size, from the existing TLVs; If traffic		limit on the TLV size, from the existing TLVs; If traffic
	engineering or some other applications are being applied per		engineering or some other applications are being applied per
	topology level later, the new TLVs can automatically inherit the		topology level later, the new TLVs can automatically inherit the
	same attributes already defined for the ``standard'' IPv4 topology		same attributes already defined for the "standard" IPv4 topology
	without going through long standard process to redefine them per		without going through long standard process to redefine them per
	topology.		topology.
	7.1. Multi-Topology TLV		7.1. Multi-Topology TLV
	TLV number of this TLV is 229. It contains one or more MTs		TLV number of this TLV is 229. It contains one or more MTs
	the router is participating in the following structure:		the router is participating in the following structure:
	x CODE - 229		x CODE - 229
	x LENGTH - total length of the value field, it should be 2		x LENGTH - total length of the value field, it SHOULD be 2
	times the number of MT components.		times the number of MT components.
	x VALUE - one or more 2-byte MT components, structured		x VALUE - one or more 2-byte MT components, structured
	as follows:		as follows:
	No. of Octets		No. of Octets
	+--------------------------------+		+--------------------------------+
	|O |A |R |R | MT ID | 2		|O |A |R |R | MT ID | 2
	+--------------------------------+		+--------------------------------+
	Bit O represents the OVERLOAD bit for the MT (only valid		Bit O represents the OVERLOAD bit for the MT (only valid
	in LSP fragment zero for MTs other than ID #0, otherwise		in LSP fragment zero for MTs other than ID #0, otherwise
	should be set to 0 on transmission and ignored on receipt.)		SHOULD be set to 0 on transmission and ignored on receipt.)
	Bit A represents the ATTACH bit for the MT (only valid		Bit A represents the ATTACH bit for the MT (only valid
	in LSP fragment zero for MTs other than ID #0, otherwise		in LSP fragment zero for MTs other than ID #0, otherwise
	should be set to 0 on transmission and ignored on receipt.)		SHOULD be set to 0 on transmission and ignored on receipt.)
	Bits R are reserved, should be set to 0 on transmission		Bits R are reserved, SHOULD be set to 0 on transmission
	and ignored on receipt.		and ignored on receipt.
	MT ID is a 12-bit field containing the ID of the topology		MT ID is a 12-bit field containing the ID of the topology
	being announced.		being announced.
	This MT TLV can advertise up to 127 MTs and it can occur multiple		This MT TLV can advertise up to 127 MTs and it can occur multiple
	times if needed within IIHs and LSP fragment zero. The result MT		times if needed within IIHs and LSP fragment zero. The result MT
	set should be the union of all the MT TLV occurrence in the packet.		set SHOULD be the union of all the MT TLV occurrence in the packet.
	Any other ISIS PDU occurrence of this TLV MUST be ignored. Lack		Any other ISIS PDU occurrence of this TLV MUST be ignored. Lack
	of MT TLV in hellos and fragment zero LSP MUST be interpreted as		of MT TLV in hellos and fragment zero LSP MUST be interpreted as
	participation of the advertising interface or router in		participation of the advertising interface or router in
	MT ID #0 only. If a router advertises MT TLV, it has to advertise		MT ID #0 only. If a router advertises MT TLV, it has to advertise
	all the MTs it participates in, specifically including topology		all the MTs it participates in, specifically including topology
	ID #0 also.		ID #0 also.
	7.2. MT Intermediate Systems TLV		7.2. MT Intermediate Systems TLV
	skipping to change at page 6, line 22 ¶		skipping to change at page 6, line 51 ¶
	|R |R |R |R | MT ID | 2		|R |R |R |R | MT ID | 2
	+--------------------------------+		+--------------------------------+
	| extended IS TLV format | 11 - 253		| extended IS TLV format | 11 - 253
	+--------------------------------+		+--------------------------------+
	. .		. .
	. .		. .
	+--------------------------------+		+--------------------------------+
	| extended IS TLV format | 11 - 253		| extended IS TLV format | 11 - 253
	+--------------------------------+		+--------------------------------+
	Bits R are reserved, should be set to 0 on transmission		Bits R are reserved, SHOULD be set to 0 on transmission
	and ignored on receipt.		and ignored on receipt.
	MT ID is a 12-bit field containing the non-zero MT ID of the		MT ID is a 12-bit field containing the non-zero MT ID of the
	topology being announced. The TLV MUST be ignored if the ID		topology being announced. The TLV MUST be ignored if the ID
	is zero. This is to ensure the consistent view of the standard		is zero. This is to ensure the consistent view of the standard
	unicast topology.		unicast topology.
	After the 2-byte MT membership format, the MT IS content is		After the 2-byte MT membership format, the MT IS content is
	in the same format as extended IS TLV, type 22 [LS01]. It		in the same format as extended IS TLV, type 22 [LS01]. It
	can contain up to 23 neighbors of the same MT if no sub-TLVs		can contain up to 23 neighbors of the same MT if no sub-TLVs
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 36 ¶
	+--------------------------------+		+--------------------------------+
	|R |R |R |R | MT ID | 2		|R |R |R |R | MT ID | 2
	+--------------------------------+		+--------------------------------+
	| extended IP TLV format | 5 - 253		| extended IP TLV format | 5 - 253
	+--------------------------------+		+--------------------------------+
	. .		. .
	. .		. .
	+--------------------------------+		+--------------------------------+
	| extended IP TLV format | 5 - 253		| extended IP TLV format | 5 - 253
	+--------------------------------+		+--------------------------------+
	Bits R are reserved, should be set to 0 on transmission
			Bits R are reserved, SHOULD be set to 0 on transmission
	and ignored on receipt.		and ignored on receipt.
	MT ID is a 12-bit field containing the non-zero ID of the		MT ID is a 12-bit field containing the non-zero ID of the
	topology being announced. The TLV MUST be ignored if the ID		topology being announced. The TLV MUST be ignored if the ID
	is zero. This is to ensure the consistent view of the standard		is zero. This is to ensure the consistent view of the standard
	unicast topology.		unicast topology.
	After the 2-byte MT membership format, the MT IPv4 content		After the 2-byte MT membership format, the MT IPv4 content
	is in the same format as extended IP reachability TLV,		is in the same format as extended IP reachability TLV,
	type 135 [LS01].		type 135 [LS01].
	skipping to change at page 7, line 39 ¶		skipping to change at page 8, line 22 ¶
	+--------------------------------+		+--------------------------------+
	|R |R |R |R | MT ID | 2		|R |R |R |R | MT ID | 2
	+--------------------------------+		+--------------------------------+
	| IPv6 Reachability format | 6 - 253		| IPv6 Reachability format | 6 - 253
	+--------------------------------+		+--------------------------------+
	. .		. .
	+--------------------------------+		+--------------------------------+
	| IPv6 Reachability format | 6 - 253		| IPv6 Reachability format | 6 - 253
	+--------------------------------+		+--------------------------------+
	Bits R are reserved, should be set to 0 on transmission		Bits R are reserved, SHOULD be set to 0 on transmission
	and ignored on receipt.		and ignored on receipt.
	MT ID is a 12-bit field containing the ID of the topology		MT ID is a 12-bit field containing the ID of the topology
	being announced. The TLV MUST be ignored if the ID		being announced. The TLV MUST be ignored if the ID
	is zero.		is zero.
	After the 2-byte MT membership format, the MT IPv6 context		After the 2-byte MT membership format, the MT IPv6 context
	is in the same format as IPv6 Reachability TLV,		is in the same format as IPv6 Reachability TLV,
	type 236 [H01].		type 236 [H01].
	This TLV can occur multiple times.		This TLV can occur multiple times.
	7.5. Reserved MT ID Values		7.5. Reserved MT ID Values
	Certain MT topologies are assigned to serve pre-determined purposes:		Certain MT topologies are assigned to serve pre-determined purposes:
	- MT ID #0: Equivalent to the ``standard'' topology.		- MT ID #0: Equivalent to the "standard" topology.
	- MT ID #1: Reserved for IPv4 in-band management		- MT ID #1: Reserved for IPv4 in-band management
	purposes.		purposes.
	- MT ID #2: Reserved for IPv6 routing topology.		- MT ID #2: Reserved for IPv6 routing topology.
	- MT ID #3: Reserved for IPv4 multicast routing topology.		- MT ID #3: Reserved for IPv4 multicast routing topology.
	- MT ID #4: Reserved for IPv6 multicast routing topology.		- MT ID #4: Reserved for IPv6 multicast routing topology.
	- MT ID #5-#3995: Reserved for IETF consensus.		- MT ID #5: Reserved for IPv6 in-band management
			purposes.
			- MT ID #6-#3995: Reserved for IETF consensus.
	- MT ID #3996-#4095: Reserved for development, experimental and		- MT ID #3996-#4095: Reserved for development, experimental and
	proprietary features [RFC3692].		proprietary features [RFC3692].
	8. MT IP Forwarding Considerations		8. MT IP Forwarding Considerations
	Using MT extension for ISIS routing can result in multiple RIBs		Using MT extension for ISIS routing can result in multiple RIBs
	on the system. The implementation and configuration MUST make		on the system. In this section we
	sure the IP packets are only traversed through the nodes and links
	intended for the topologies and applications. In this section we
	list some of the known considerations for IP forwarding in various		list some of the known considerations for IP forwarding in various
	MT scenario. Certain deployment scenarios presented here		MT scenario. Certain deployment scenarios presented here
	imply different trade-offs in terms of deployment difficulties		imply different trade-offs in terms of deployment difficulties
	and advantages obtained.		and advantages obtained.
	8.1. Each MT belong to a distinct address family		8.1. Each MT belong to a distinct address family
	In this case, each MT related routes are installed into a		In this case, each MT related routes are installed into a
	separate RIB. Multiple topologies can share the same ISIS interface		separate RIB. Multiple topologies can share the same ISIS interface
	on detecting the incoming packet address family. As an example,		on detecting the incoming packet address family. As an example,
	skipping to change at page 8, line 54 ¶		skipping to change at page 9, line 35 ¶
	MTs have their dedicated interfaces, and those interfaces can be		MTs have their dedicated interfaces, and those interfaces can be
	associated with certain MT RIBs and FIBs.		associated with certain MT RIBs and FIBs.
	8.2.2. Multiple MTs share an interface with overlapping addresses		8.2.2. Multiple MTs share an interface with overlapping addresses
	Some additional mechanism is needed to select the correct RIBs		Some additional mechanism is needed to select the correct RIBs
	for the incoming IP packets to determine the correct RIB to make		for the incoming IP packets to determine the correct RIB to make
	a forwarding decision. For example, if the topologies are		a forwarding decision. For example, if the topologies are
	QoS partitioned, then the DSCP bits in the IP packet header can		QoS partitioned, then the DSCP bits in the IP packet header can
	be utilized to make the decision. Some IP header or even packet		be utilized to make the decision. Some IP header or even packet
	data information may be checked to make the forwarding table		data information MAY be checked to make the forwarding table
	selection, such as source IP address in the header can be used		selection, such as source IP address in the header can be used
	to determine the desired forwarding behavior.		to determine the desired forwarding behavior.
			This topic is not unique to IS-IS or even to Multi-topology, it
			is a local policy and configuration decision to make sure the
			inbound traffic uses the correct forwarding tables. For example,
			preferred customer packets are sent through a L2TP towards the
			high-bandwidth upstream provider, and other packets are sent
			through a different L2TP to a normal-bandwidth provider. Those
			mechanism are not part of the L2TP protocol specifications.
	The generic approach of packet to multiple MT RIB mapping over		The generic approach of packet to multiple MT RIB mapping over
	the same inbound interface is outside the scope of this draft.		the same inbound interface is outside the scope of this document.
	8.2.3. Multiple MTs share an interface with non-overlapping addresses		8.2.3. Multiple MTs share an interface with non-overlapping addresses
	When there is no overlap in the address space among all the MTs,		When there is no overlap in the address space among all the MTs,
	strictly speaking the destination address space classifies the		strictly speaking the destination address space classifies the
	topology a packet belongs to. It is possible to install routes		topology a packet belongs to. It is possible to install routes
	from different MTs into a shared RIB. As an example of such a		from different MTs into a shared RIB. As an example of such a
	deployment, a special ISIS topology can be setup for certain		deployment, a special ISIS topology can be setup for certain
	EBGP nexthop addresses.		EBGP nexthop addresses.
	8.3 Some MTs are not used for forwarding purpose		8.3 Some MTs are not used for forwarding purpose
	MT in ISIS may be used even if the resulting RIB is not used for		MT in ISIS MAY be used even if the resulting RIB is not used for
	forwarding purposes. As an example, multicast RPF check can be		forwarding purposes. As an example, multicast RPF check can be
	performed on a different RIB than the standard unicast RIB albeit		performed on a different RIB than the standard unicast RIB albeit
	an entirely different RIB is used for the multicast forwarding.		an entirely different RIB is used for the multicast forwarding.
	However, an incoming packet must be still clearly identified as		However, an incoming packet MUST be still clearly identified as
	belonging to a unique topology.		belonging to a unique topology.
	9. MT Network Management Considerations		9. MT Network Management Considerations
	When multiple ISIS topologies exist within a domain, some of the		When multiple ISIS topologies exist within a domain, some of the
	routers can be configured to participate in a subset of the MTs		routers can be configured to participate in a subset of the MTs
	in the network. This section discusses some of the options we		in the network. This section discusses some of the options we
	have to enable operations or the network management stations to		have to enable operations or the network management stations to
	access those routers.		access those routers.
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 43 ¶
	optionally installed into the default RIB.		optionally installed into the default RIB.
	The advantages of duplicate 'mgmt' routes in both RIBs include:		The advantages of duplicate 'mgmt' routes in both RIBs include:
	the network management utilities on the system does not have to be		the network management utilities on the system does not have to be
	modified to use specific RIB other than the default RIB; the 'mgmt'		modified to use specific RIB other than the default RIB; the 'mgmt'
	topology can share the same link with the default topology if so		topology can share the same link with the default topology if so
	designed.		designed.
	9.2. Extend the default topology to all the nodes		9.2. Extend the default topology to all the nodes
	Even in the case default topology is not used on some of the nodes		Even in the case default topology is not used on some of the nodes
	in the IP forwarding, we may want to extend the default topology		in the IP forwarding, we MAY want to extend the default topology
	to those nodes for the purpose of network management. Operators		to those nodes for the purpose of network management. Operators
	SHOULD set high cost on the links which belong to the extended		SHOULD set high cost on the links which belong to the extended
	portion of the default topology. This way the IP data traffic		portion of the default topology. This way the IP data traffic
	will not be forwarded through those nodes during network topology		will not be forwarded through those nodes during network topology
	changes.		changes.
	10. Acknowledgments		10. Acknowledgments
	The authors would like to thank Andrew Partan, Dino Farinacci,		The authors would like to thank Andrew Partan, Dino Farinacci,
	Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong,		Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong,
	Pekka Savola, Mike Shand, Shankar Vemulapalli and Les Ginsberg		Pekka Savola, Mike Shand, Shankar Vemulapalli and Les Ginsberg
	for the discussion, their review, comments and contributions to		for the discussion, their review, comments and contributions to
	this draft.		this document.
	11. Security Consideration		11. Security Consideration
	ISIS security applies to the work presented. No specific security		ISIS security applies to the work presented. No specific security
	issues with the proposed solutions are known. The authentication		issues with the proposed solutions are known. The authentication
	procedure for ISIS PDUs is the same regardless of MT information		procedure for ISIS PDUs is the same regardless of MT information
	inside the ISIS PDUs.		inside the ISIS PDUs.
			Note that an authentication mechanism, such as the one defined in
			[RFC3567] SHOULD be applied if there is high risk resulting
			from modification of multi-topology information.
			As described in section 8.2.2, multiple topologies share an
			interface in the same address space, some mechanism beyond
			IS-IS need to be used to select the right forwarding table
			for an inbound packet. A misconfiguration on the system or
			a packet with spoofed source address for example can lead to
			packet loss or unauthorized use of premium network resource.
	12. IANA Considerations		12. IANA Considerations
	IANA is requested to create a new registry, "IS-IS multi-topology ID		This document defines the following new IS-IS TLV types, which have
	values" with the assignment listed in Section 7.5 of this document		already been reflected in the IANA IS-IS TLV code-point registry:
	and registration policies for future assignments.
	IANA is also requested to update the IS-IS codepoint registry		Name Value
	(http://www.iana.org/assignments/isis-tlv-codepoints) so that TLV
	codes 222, 229, 235 and 237 refer to this document's RFC number.
	[[ note to the RFC-editor: the above paragraph may be removed or		MT-ISN 222
	reworded prior to RFC publication ]]		M-Topologies 229
			MT IP. Reach 235
			MT IPv6 IP. Reach 237
			IANA is requested to create a new registry, "IS-IS multi-topology ID
			values" with the assignment listed in Section 7.5 of this document
			and registration policies [RFC2434] for future assignments. The
			MT ID values range 6-3095 are allocated through Expert Review;
			values in the range of 3096-4095 are reserved for Private Use.
			In all cases, assigned values are to be registered with IANA.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[ISO10589] ISO. Intermediate System to Intermediate System Routing		[ISO10589] ISO. Intermediate System to Intermediate System Routing
	Exchange Protocol for Use in Conjunction with the		Exchange Protocol for Use in Conjunction with the
	Protocol for Providing the Connectionless-Mode Network		Protocol for Providing the Connectionless-Mode Network
	Service. ISO 10589, 1992.		Service. ISO 10589, 1992.
	[RFC1195] R. Callon. Use of OSI ISIS for Routing in TCP/IP and		[RFC1195] R. Callon. Use of OSI ISIS 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.
	[RFC3692] Narten, T., "Assigning Experimental and Testing		[RFC3692] Narten, T., "Assigning Experimental and Testing
	Numbers Considered Useful", BCP 82, RFC 3692, January		Numbers Considered Useful", BCP 82, RFC 3692, January
	2004.		2004.
			[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
			an IANA Considerations Section in RFCs", BCP 26,
			RFC 2434, October 1998.
	13.2. Informative References		13.2. Informative References
			[RFC3567] Li, T. and R. Atkinson, "Intermediate System to
			Intermediate System (IS-IS) Cryptographic
			Authentication", RFC 3567, July 2003.
	[LS01] T. Li and H. Smit. IS-IS Extensions for Traffic		[LS01] T. Li and H. Smit. IS-IS Extensions for Traffic
	Engineering. RFC 3784, May 2005.		Engineering. RFC 3784, May 2005.
	[H01] C. Hopps. Routing IPv6 with IS-IS.		[H01] C. Hopps. Routing IPv6 with IS-IS.
	draft-ietf-isis-ipv6-06.txt, May 2004. (work in progress)		draft-ietf-isis-ipv6-07.txt, October 2007.
			(work in progress)
	14. Authors' Addresses		14. Authors' Addresses
	Tony Przygienda		Tony Przygienda
	Z2 Sagl		Z2 Sagl
	Via Rovello 32		Via Rovello 32
	CH-6942 Savosa		CH-6942 Savosa
	prz@net4u.ch		prz@net4u.ch
	Naiming Shen		Naiming Shen
	skipping to change at page 11, line 40 ¶		skipping to change at page 13, line 5 ¶
	225 West Tasman Drive		225 West Tasman Drive
	San Jose, CA, 95134 USA		San Jose, CA, 95134 USA
	naiming@cisco.com		naiming@cisco.com
	Nischal Sheth		Nischal Sheth
	Juniper Networks		Juniper Networks
	1194 North Mathilda Avenue		1194 North Mathilda Avenue
	Sunnyvale, CA 94089 USA		Sunnyvale, CA 94089 USA
	nsheth@juniper.net		nsheth@juniper.net
	Intellectual Property		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed to
	to pertain to the implementation or use of the technology described		pertain to the implementation or use of the technology described in
	in this document or the extent to which any license under such		this document or the extent to which any license under such rights
	rights might or might not be available; nor does it represent that		might or might not be available; nor does it represent that it has
	it has made any independent effort to identify any such rights.		made any independent effort to identify any such rights. Information
	Information on the procedures with respect to rights in RFC		on the procedures with respect to rights in RFC documents can be
	documents can be found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use		attempt made to obtain a general license or permission for the use of
	of such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository at
	at http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Full Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The IETF Trust (2007).
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on		This document is subject to the rights, licenses and restrictions
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		contained in BCP 78, and except as set forth therein, the authors
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND		retain all their rights.
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
			AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR		THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
	ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A		IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
	PARTICULAR PURPOSE.		PURPOSE.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 47 change blocks.
	83 lines changed or deleted		152 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/