< draft-lamparter-isis-p2mp-00.txt		draft-lamparter-isis-p2mp-01.txt >
	Network Working Group C. Franke		Network Working Group C. Franke
	Internet-Draft D. Lamparter		Internet-Draft D. Lamparter
	Intended status: Standards Track NetDEF		Intended status: Standards Track NetDEF
	Expires: January 08, 2016 July 07, 2015		Expires: April 21, 2016 C. Hopps
			Deutsche Telekom
			October 19, 2015
	IS-IS Point-to-Multipoint operation		IS-IS Point-to-Multipoint operation
	draft-lamparter-isis-p2mp-00		draft-lamparter-isis-p2mp-01
	Abstract		Abstract
	This document describes a new mode operation for IS-IS. In addition		This document describes a new mode operation for IS-IS. In addition
	to the existing LAN and point-to-point modes of operation, a point-		to the existing LAN and point-to-point modes of operation, a point-
	to-multipoint mode is defined. This mode is useful for operation		to-multipoint mode is defined. This mode is useful for operation
	both on networks with more than two routers where multicast is		both on networks with more than two routers where multicast is
	expensive in comparison to unicast, as well on networks where		expensive in comparison to unicast, as well on networks where
	creating a LAN pseudonode cannot adequately reflect metrics.		creating a LAN pseudonode cannot adequately reflect metrics.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 37 ¶
	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 January 08, 2016.		This Internet-Draft will expire on April 21, 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
	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. P2MP Pseudocircuits . . . . . . . . . . . . . . . . . . . . . 3		2. Point-To-Multipoint Pseudocircuits . . . . . . . . . . . . . 3
	2.1. Pseudocircuit behaviour . . . . . . . . . . . . . . . . . 3		2.1. Pseudocircuit behaviour . . . . . . . . . . . . . . . . . 3
	2.1.1. Representation in LSPs . . . . . . . . . . . . . . . 3		2.1.1. Representation in LSPs . . . . . . . . . . . . . . . 3
	2.1.2. Forwarding . . . . . . . . . . . . . . . . . . . . . 4		2.1.2. Forwarding . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Neighbor IS discovery . . . . . . . . . . . . . . . . . . 4		2.2. Neighbor IS discovery . . . . . . . . . . . . . . . . . . 3
	2.2.1. Manual configuration . . . . . . . . . . . . . . . . 4		2.2.1. Manual configuration . . . . . . . . . . . . . . . . 4
	2.2.2. Lower layer autodiscovery . . . . . . . . . . . . . . 4		2.2.2. Lower layer autodiscovery . . . . . . . . . . . . . . 4
	2.2.3. Multicast autodiscovery . . . . . . . . . . . . . . . 4		2.2.3. Multicast autodiscovery . . . . . . . . . . . . . . . 4
	2.3. Adjacency formation . . . . . . . . . . . . . . . . . . . 5		2.3. Adjacency formation . . . . . . . . . . . . . . . . . . . 5
	2.4. Pseudocircuit teardown . . . . . . . . . . . . . . . . . 5		2.4. Pseudocircuit teardown . . . . . . . . . . . . . . . . . 5
	3. PDU generation and processing . . . . . . . . . . . . . . . . 6		3. Configuration model . . . . . . . . . . . . . . . . . . . . . 5
	3.1. LSP, CSNP, PSNP and all other non-Hello PDU types . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	3.2. LAN and P2P Hellos . . . . . . . . . . . . . . . . . . . 6		5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
	3.3. P2MP Hello PDUs . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	3.3.1. Without Three-way Adjacency TLV . . . . . . . . . . . 6		7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3.2. With Three-way Adjacency TLV . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. PDU encoding . . . . . . . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 6
	4.1. P2MP Hello PDU . . . . . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. Misconfiguration With P2P over LAN . . . . . . . . . 6
	6. Configuration model . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The core functionality of the protocol outlined in this document		The core functionality of the protocol outlined in this document
	consists of an additional Subnetwork dependent function per Section 8		consists of an additional Subnetwork dependent function per Section 8
	of ISO/IEC 10589:2002 [IS-IS]. In that regard, the next section can		of ISO/IEC 10589:2002 [IS-IS]. In that regard, the next section can
	be understood as new section "8.5 Point-to-multipoint networks".		be understood as new section "8.5 Point-to-multipoint networks".
	The outlined protocol is remotely similar to the derelict section		The outlined protocol is remotely similar to the derelict section
	"8.3 ISO 8208 subnetworks" [X.25] in that multiple point-to-point		"8.3 ISO 8208 subnetworks" [X.25] in that multiple point-to-point
	adjacencies are established on an interface.		adjacencies are established on an interface.
	Point-to-multipoint operation of IS-IS is thus not a new idea; in		Point-to-multipoint operation of IS-IS is thus not a new idea; in
	fact section 6.2 already mentions "multipoint links." This document		fact section 6.2 already mentions "multipoint links." This document
	re-enables the concept.		re-enables the concept.
	2. P2MP Pseudocircuits		2. Point-To-Multipoint Pseudocircuits
	In place of ISO 8473 call management [CLNS] establishing sessions,		In place of ISO 8473 call management [CLNS] establishing sessions,
	this document establishes pairwise "pseudocircuits" between two IS on		this document establishes pairwise "pseudocircuits" between two IS on
	a common medium. Multiple such pseudocircuits can normally exist on		a common medium. Multiple such pseudocircuits can normally exist on
	one P2MP interface.		one P2MP (Point-To-Multipoint) interface.
	Each pseudocircuit operates, aside from subnetwork attachment		Each pseudocircuit operates, aside from subnetwork attachment
	procedures, exactly as a PtP link.		procedures, exactly as a P2P (Point-to-Point) link.
	It should be noted that while the Multicast autodiscovery mechanism		It should be noted that while the Multicast autodiscovery mechanism
	requires broadcast capability, no other part of the protocol does.		requires broadcast capability, no other part of the protocol does.
	The P2MP interface type can be used on non-transitive and/or non-		The P2MP interface type can be used on non-transitive and/or non-
	broadcast interfaces.		broadcast interfaces.
	2.1. Pseudocircuit behaviour		2.1. Pseudocircuit behaviour
	An implementation maintains a set of pseudocircuits per P2MP		An implementation maintains a set of pseudocircuits per P2MP
	interface. Each pseudocircuit is uniquely identified by the local		interface. Each pseudocircuit is uniquely identified by the local
	skipping to change at page 3, line 43 ¶		skipping to change at page 3, line 35 ¶
	Each participating system MUST use a consistent SNPA address per		Each participating system MUST use a consistent SNPA address per
	local interface. A change in SNPA address results in all neighbors		local interface. A change in SNPA address results in all neighbors
	treating the interface as distinct from the previous one. A system		treating the interface as distinct from the previous one. A system
	MAY support multiple SNPA addresses per interface by treating them as		MAY support multiple SNPA addresses per interface by treating them as
	distinct interfaces.		distinct interfaces.
	Unnumbered media are not supported by this protocol. Each		Unnumbered media are not supported by this protocol. Each
	participant on a link MUST have an unique SNPA address on that link.		participant on a link MUST have an unique SNPA address on that link.
	As pseudocircuits are dynamic in nature, they must be created and
	destroyed as needed.
	2.1.1. Representation in LSPs		2.1.1. Representation in LSPs
	Pseudocircuits are represented in LSPs as a regular PtP circuit would		Pseudocircuits are represented in LSPs as a regular P2P circuit would
	be. As a result, their treatment in SPF calculations is also		be. As a result, their treatment in SPF calculations is also
	identical to PtP circuits.		identical to P2P circuits.
	2.1.2. Forwarding		2.1.2. Forwarding
	In scenarios where pseudocircuits do not form a full mesh of all		In scenarios where pseudocircuits do not form a full mesh of all
	participants on a medium, the best path for a packet may be through		participants on a medium, the best path for a packet may be through
	the same interface as the one it was received on.		the same interface as the one it was received on.
	Systems implementing this specification MUST therefore support		Systems implementing this specification MUST therefore support
	forwarding packets on the same interface that they were received on.		forwarding packets on the same interface that they were received on.
	This applies only to interfaces configured for P2MP operation.		This applies only to interfaces configured for P2MP operation.
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 4 ¶
	In scenarios where pseudocircuits do not form a full mesh of all		In scenarios where pseudocircuits do not form a full mesh of all
	participants on a medium, the best path for a packet may be through		participants on a medium, the best path for a packet may be through
	the same interface as the one it was received on.		the same interface as the one it was received on.
	Systems implementing this specification MUST therefore support		Systems implementing this specification MUST therefore support
	forwarding packets on the same interface that they were received on.		forwarding packets on the same interface that they were received on.
	This applies only to interfaces configured for P2MP operation.		This applies only to interfaces configured for P2MP operation.
	2.2. Neighbor IS discovery		2.2. Neighbor IS discovery
	The discovery machinery produces as output a "candidate neighbor		The discovery machinery produces as output a "candidate neighbor
	list," which is a list of possible neighbor's SNPAs and is maintained		list," which is a list of possible neighbor's SNPAs and is maintained
	per P2MP interface. Additional information (metric, etc.) MAY be		per P2MP interface. Adding and removing entries to the candidate
	associated with the SNPA, but this is not part of the discovery		neighbor list results in pseudocircuit creation and deletion.
	mechanism.
	The candidate neighbor list is conceptual in nature; adding and
	removing entries results in pseudocircuit creation and deletion. It
	need not be implemented as an actual list.
	The list is the union of the result of each of the following sources		A neighbors presence on the candidate list may be supported by
	of neighbor information. A neighbor may be listed by multiple		multiple sources. These sources are described in the following
	sources: it MUST NOT be removed while any source still lists it.		sections
	The IS-IS implementation SHOULD provide user configuration to disable		The IS-IS implementation SHOULD provide user configuration to disable
	individual mechanisms and/or filter candidate neighbors both as a		or filter individual sources.
	security and as misconfiguration preventing measure.
	2.2.1. Manual configuration		2.2.1. Manual configuration
	A list of neighbor IS MAY be configured by the user, providing		A list of neighbor IS MAY be configured by the user, providing
	possible neighbor's SNPAs on an interface.		possible neighbor's SNPAs on an interface.
	2.2.2. Lower layer autodiscovery		2.2.2. Lower layer autodiscovery
	Lower protocol layers (VPLS, IEEE 802.11) may be able to provide a		Lower protocol layers (VPLS, IEEE 802.11) may be able to provide a
	list of attached neighbors. This list MAY be fed into the candidate		list of attached neighbors. This list MAY be fed into the candidate
	neighbor list.		neighbor list.
	2.2.3. Multicast autodiscovery		2.2.3. Multicast autodiscovery
	For broadcast capable networks, this document defines an		For broadcast capable networks, this document defines an
	autodiscovery mechanism based on multicasting Hello packets. This		autodiscovery mechanism based on multicasting Hello packets. This
	mechanism MAY be disabled by the user, but MUST be implemented for		mechanism MAY be disabled by the user, but MUST be implemented for
	all lower layer link types with (limited or full) broadcast		all lower layer link types with (limited or full) broadcast
	capability.		capability.
	Multicast autodiscovery P2MP Hello PDUs are distinguished by not		A multicast autodiscovery packet is defined as a P2P IIH which is
	containing a RFC5303 Three-Way Adjacency TLV. Receiving such a Hello		multicast over the LAN media as defined in [RFC5309]. Additionally
	places the sending IS on the candidate list for as long as the PDU's		it must include a Three-Way Adjacency TLV as defined in [RFC5303]
	holdtime indicates.		indicating the circuit is in the DOWN state (i.e., 1 octet of value
			indicating the DOWN state). Receiving such a Hello places the
			sending IS on the candidate list for as long as the PDU's holdtime
			indicates.
	A system MAY implement a receive-only passive multicast autodiscovery		A system MAY implement a receive-only passive multicast autodiscovery
	mode where it adds candidates (forms pseudocircuits) on receiving		mode where it adds candidates (forms pseudocircuits) on receiving
	P2MP Hello PDUs, but does not send such PDUs itself.		autodiscovery PDU, but does not send such PDUs itself.
	If either passive or full multicast autodiscovery is enabled,		If either passive or full multicast autodiscovery is enabled,
	receiving a P2MP Hello PDU with a Three-Way Adjacency TLV also adds		receiving a unicast autodiscovery PDU also adds the neighbor to the
	the neighbor to the candidate list.		candidate list.
	2.3. Adjacency formation		2.3. Adjacency formation
	Since there is no underlying protocol layer partitioning the link		Since there may be no underlying protocol layer partitioning the link
	into actual PtP circuits in this case, additional handling is		into actual P2P circuits in this case, additional handling is
	required on bringing up the individual pseudocircuit adjacencies.		required on bringing up the individual pseudocircuit adjacencies.
	To prevent different pseudocircuits from "bleeding" into each other,		To prevent different pseudocircuits from "bleeding" into each other,
	implementations of this protocol MUST enable [RFC5303] on all P2MP		implementations of this protocol MUST enable [RFC5303] on all P2MP
	pseudocircuits, with changes as follows:		pseudocircuits, with changes as follows:
	o Received IIH PDUs on P2MP pseudocircuits without the Point-to-		o Received IIH PDUs on P2MP pseudocircuits without the Point-to-
	Point Three-Way Adjacency option MUST be discarded. The TLV is		Point Three-Way Adjacency option MUST be discarded.
	not optional on pseudocircuit adjacencies but rather mandatory.
	2.4. Pseudocircuit teardown		2.4. Pseudocircuit teardown
	Pseudocircuits are destroyed when their PtP state machine has		Pseudocircuits are destroyed when their P2P state machine has
	transitioned into "Down" state and they are no longer listed as		transitioned into "Down" state and they are no longer supported as a
	candidates by any discovery mechanism. The conditions for		candidate by any discovery mechanism.
	pseudocircuit removal are thus:
	o PtP adjacency timeout functionality (IS-IS section 8.2.6 [IS-IS])
	has moved the pseudocircuit to Down state, or it never moved out
	of Down state
	o The holdtime of any multicast autodiscovery P2MP Hello PDUs has
	expired.
	o Manual configuration or lower layer autodiscovery no longer lists
	the neighbor.
	As long as a pseudocircuit is present, its PtP state machine will, as		As long as a pseudocircuit is present, its P2P state machine will, as
	expected for PtP circuits, trigger transmission of further Hello		expected for P2P circuits, trigger transmission of further Hello
	PDUs, even when it is in Down state.		PDUs, even when it is in Down state.
	3. PDU generation and processing		3. Configuration model
	3.1. LSP, CSNP, PSNP and all other non-Hello PDU types
	All PDU types that are not Hello PDUs, e.g. L1/L2 LSP PDUs, L1/L2
	CSNP/PSNP PDUs, FS-LSP, FS-CSNP and FS-PSNP PDUs are processed on
	P2MP interfaces by dispatching them to an individual pseudocircuit by
	looking up the PDU's source address in the interface's list of P2MP
	pseudocircuits. This includes all functions defined in Section 7 of
	ISO/IEC 10589:2002 [IS-IS] and PDUs added in [RFC7176] and [RFC7356].
	While possible, this document does not suggest sending such PDUs to
	multicast destinations. All systems MUST send these PDUs to unicast
	lower layer destinations so that they are received only by the
	pseudocircuit's neighbor system. However, systems SHOULD NOT check
	the destination address on receipt to allow future optimisations.
	3.2. LAN and P2P Hellos
	Received LAN and P2P Hello PDUs MUST be discarded when received on an
	interface configured for P2MP operation. The system MAY notify the
	operator of such a misconfiguration.
	TODO: hitless migration possible?
	3.3. P2MP Hello PDUs
	P2MP Hello PDUs are divided in two categories depending on the
	presence of a RFC5303 Three-way Adjacency TLV.
	3.3.1. Without Three-way Adjacency TLV
	For each P2MP interface that has the multicast autodiscovery
	mechanism enabled, a system periodically sends P2MP Hello PDUs
	without Three-way Adjacency TLV to a lower layer specific multicast
	address. The periodic timer SHOULD be configurable and is subject to
	jitter per Section 10.1 of ISO/IEC 10589:2002 [IS-IS].
	On receipt, such PDUs are not processed on any pseudocircuit's PtP
	state machine. They are processed on pseudocircuit management level
	as described in :
	o If no pseudocircuit matches the PDU's lower layer source address,
	one is created for that address
	o The pseudocircuit is held in existence at least until the PDU's
	holdtime expires.
	No information other than the neighbor's SNPA is carried from the PDU
	onto the pseudocircuit, thus most TLVs that are normally valid in
	Hellos become pointless. However, all TLVs that affect PDU
	processing (in particular authentication TLVs) are processed
	normally.
	On IEEE 802 lower layers that support 48bit MAC addresses, the
	AllIntermediateSystems multicast address (09-00-2B-00-00-05) is used
	as destination when sending these PDUs.
	3.3.2. With Three-way Adjacency TLV
	P2MP Hello PDUs with a RFC5303 Three-way Adjacency TLV are both
	processed and generated by the PtP Hello state machine (Section 8.2
	of ISO/IEC 10589:2002 [IS-IS]) of their associated pseudocircuit.
	This implies that received PDUs are dispatched by looking up their
	source SNPA address among the pseudocircuits associated with the
	receiving interface (possibly creating a pseudocircuit).
	For Hello PDUs sent by the pseudocircuit's PtP Hello state machine,
	the destination SNPA address is set to the pseudocircuit's neighbor
	SNPA address.
	TLV validity and processing is exactly as for PtP Hellos.
	4. PDU encoding
	(Note this section follows ISO 10589 section 9, particularly in
	numbering bits starting at 1 for the LSB.)
	4.1. P2MP Hello PDU
	Figure 1: P2MP Hello PDU format
	MSB LSB MSB LSB
	8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
	+---+---+---+---+---+---+---+---+ - + - + - + - + - + - + - + - +
	| 0x83 (Protocol Discriminator) |
	+---+---+---+---+---+---+---+---+
	| Length Indicator |
	+---+---+---+---+---+---+---+---+
	| 0x01 (Version/ID Extension) |
	+---+---+---+---+---+---+---+---+
	| ID Length |
	+---+---+---+---+---+---+---+---+
	| R R R | TBD-PDU (PDU Type)|
	+---+---+---+---+---+---+---+---+
	| 0x01 (Version) |
	+---+---+---+---+---+---+---+---+
	| R R R R R R R R |
	+---+---+---+---+---+---+---+---+
	| Maximum Area Addresses |
	+---+---+---+---+---+---+---+---+
	| R R R R R R |CircTyp|
	+---+---+---+---+---+---+---+---+
	| Source ID |
	: (ID Length) :
	: :
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	| Holding Time |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	| PDU Length |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	: Variable Length Fields (TLVs) :
	: :
	All fields function exactly as for Point-to-Point IS-IS hello PDUs,
	as specified in Section 9.7 of ISO/IEC 10589:2002 [IS-IS].
	Note the Local Circuit ID field is absent. Its function is replaced
	by [RFC5303].
	5. IANA Considerations
	IANA is requested to allocate a value from the "IS-IS PDU Registry"
	as follows:
	Type: TBD-PDU
	Description: P2MP-HELLO-PDU
	Reference: This document
	Applicability of sub-TLVs for this PDU (per "TLV Codepoints		TODO: YANG model
	Registry") is per the "IIH" column.
	6. Configuration model		4. Security Considerations
	TODO: YANG model.		TODO.
	7. Security Considerations		5. Privacy Considerations
	TODO.		TODO.
	8. Privacy Considerations		6. Acknowledgements
	TODO.		Acknowledge Les Ginsberg for pointing out that P2P Hellos rather than
			LAN hellos could and should be used.
	9. Acknowledgements		7. Change Log
	TODO.		October 2015 [-01]: Moved from new P2MP Hello PDU to using existing
			P2P PDU.
	10. References		July 2015 [-00]: Initial Version
	10.1. Normative References		8. References
			8.1. Normative References
	[IS-IS] ISO/IEC, "Intermediate System to Intermediate System		[IS-IS] ISO/IEC, "Intermediate System to Intermediate System
	Intra-Domain Routing Exchange Protocol for use in		Intra-Domain Routing Exchange Protocol for use in
	Conjunction with the Protocol for Providing the		Conjunction with the Protocol for Providing the
	Connectionless-mode Network Service (ISO 8473)", ISO/IEC		Connectionless-mode Network Service (ISO 8473)", ISO/IEC
	10589:2002, Second Edition, 2002.		10589:2002, Second Edition, 2002.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way		[RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way
	Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303,		Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303,
	October 2008.		October 2008.
	10.2. Informative References		[RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation
			over LAN in Link State Routing Protocols", RFC 5309, DOI
			10.17487/RFC5309, October 2008,
			<http://www.rfc-editor.org/info/rfc5309>.
			8.2. Informative References
	[CLNS] ISO/IEC, "Protocol for providing the connectionless-mode		[CLNS] ISO/IEC, "Protocol for providing the connectionless-mode
	network service: Protocol specification", ISO/IEC		network service: Protocol specification", ISO/IEC
	8473-1:1998, 1998.		8473-1:1998, 1998.
	[RFC7176] Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D.,		[RFC7176] Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D.,
	and A. Banerjee, "Transparent Interconnection of Lots of		and A. Banerjee, "Transparent Interconnection of Lots of
	Links (TRILL) Use of IS-IS", RFC 7176, May 2014.		Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
	[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding		[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
	Scope Link State PDUs (LSPs)", RFC 7356, September 2014.		Scope Link State PDUs (LSPs)", RFC 7356, September 2014.
	[X.25] ISO/IEC, "X.25 Packet Layer Protocol for Data Terminal		[X.25] ISO/IEC, "X.25 Packet Layer Protocol for Data Terminal
	Equipment", ISO/IEC 8208:2000, 2000.		Equipment", ISO/IEC 8208:2000, 2000.
			Appendix A. Misconfiguration With P2P over LAN
			TODO.
	Authors' Addresses		Authors' Addresses
	Christian Franke		Christian Franke
	NetDEF		NetDEF
	Leipzig		Leipzig
	DE		DE
	Email: chris@opensourcerouting.org		Email: chris@opensourcerouting.org
	David Lamparter		David Lamparter
	NetDEF		NetDEF
	Leipzig 04103		Leipzig 04103
	Germany		Germany
	Email: david@opensourcerouting.org		Email: david@opensourcerouting.org
			Christian E. Hopps
			Deutsche Telekom
			Email: chopps@chopps.org
End of changes. 39 change blocks.
	216 lines changed or deleted		72 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/