< draft-acee-lsr-ospf-transport-instance-01.txt		draft-acee-lsr-ospf-transport-instance-02.txt >
	LSR Workgroup A. Lindem		LSR Workgroup A. Lindem
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track Y. Qu		Intended status: Standards Track Y. Qu
	Expires: May 6, 2021 Futurewei		Expires: August 23, 2021 Futurewei
	A. Roy		A. Roy
	Arrcus, Inc.		Arrcus, Inc.
	S. Mirtorabi		S. Mirtorabi
	Cisco Systems		Cisco Systems
	November 2, 2020		February 19, 2021
	OSPF Transport Instance Extensions		OSPF Transport Instance Extensions
	draft-acee-lsr-ospf-transport-instance-01		draft-acee-lsr-ospf-transport-instance-02
	Abstract		Abstract
	OSPFv2 and OSPFv3 include a reliable flooding mechanism to		OSPFv2 and OSPFv3 include a reliable flooding mechanism to
	disseminate routing topology and Traffic Engineering (TE) information		disseminate routing topology and Traffic Engineering (TE) information
	within a routing domain. Given the effectiveness of these		within a routing domain. Given the effectiveness of these
	mechanisms, it is convenient to envision using the same mechanism for		mechanisms, it is convenient to envision using the same mechanism for
	dissemination of other types of information within the domain.		dissemination of other types of information within the domain.
	However, burdening OSPF with this additional information will impact		However, burdening OSPF with this additional information will impact
	intra-domain routing convergence and possibly jeopardize the		intra-domain routing convergence and possibly jeopardize the
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 May 6, 2021.		This Internet-Draft will expire on August 23, 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 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	4. OSPF Transport Instance . . . . . . . . . . . . . . . . . . . 4		4. OSPF Transport Instance . . . . . . . . . . . . . . . . . . . 4
	4.1. OSPFv2 Transport Instance Packet Differentiation . . . . 5		4.1. OSPFv2 Transport Instance Packet Differentiation . . . . 5
	4.2. OSPFv3 Transport Instance Packet Differentiation . . . . 5		4.2. OSPFv3 Transport Instance Packet Differentiation . . . . 5
	4.3. Instance Relationship to Normal OSPF Instances . . . . . 5		4.3. Instance Relationship to Normal OSPF Instances . . . . . 5
	4.4. Network Prioritization . . . . . . . . . . . . . . . . . 5		4.4. Network Prioritization . . . . . . . . . . . . . . . . . 5
	4.5. OSPF Transport Instance Omission of Routing Calculation . 6		4.5. OSPF Transport Instance Omission of Routing Calculation . 6
	4.6. Non-routing Instance Separation . . . . . . . . . . . . . 6		4.6. Non-routing Instance Separation . . . . . . . . . . . . . 6
	4.7. Non-Routing Sparse Topologies . . . . . . . . . . . . . . 7		4.7. Non-Routing Sparse Topologies . . . . . . . . . . . . . . 7
	4.7.1. Remote OSPF Neighbor . . . . . . . . . . . . . . . . 7		4.7.1. Remote OSPF Neighbor . . . . . . . . . . . . . . . . 7
	4.8. Multiple Topologies . . . . . . . . . . . . . . . . . . . 8		4.8. Multiple Topologies . . . . . . . . . . . . . . . . . . . 8
	5. OSPF Transport Instance Information Encoding . . . . . . . . 8		5. OSPF Transport Instance Information (TII) Encoding . . . . . 8
	5.1. OSPFv2 Transport Instance Information Encoding . . . . . 9		5.1. OSPFv2 Transport Instance Information Encoding . . . . . 8
	5.2. OSPFv3 Transport Instance Information Encoding . . . . . 9		5.2. OSPFv3 Transport Instance Information Encoding . . . . . 9
	6. Manageability Considerations . . . . . . . . . . . . . . . . 9		5.3. Transport Instance Information (TII) TLV Encoding . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5.3.1. Top-Level TII Application TLV . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. Manageability Considerations . . . . . . . . . . . . . . . . 11
	9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		8.1. OSPFv2 Opaque LSA Type Assignment . . . . . . . . . . . . 11
	10.2. Informative References . . . . . . . . . . . . . . . . . 10		8.2. OSPFv3 LSA Function Code Assignment . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		8.3. OSPF Transport Instance Information Top-Level TLV
			Registry . . . . . . . . . . . . . . . . . . . . . . . . 12
			9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
			10.1. Normative References . . . . . . . . . . . . . . . . . . 12
			10.2. Informative References . . . . . . . . . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	OSPFv2 [RFC2328] and OSPFv3 [RFC5340] include a reliable flooding		OSPFv2 [RFC2328] and OSPFv3 [RFC5340] include a reliable flooding
	mechanism to disseminate routing topology and Traffic Engineering		mechanism to disseminate routing topology and Traffic Engineering
	(TE) information within a routing domain. Given the effectiveness of		(TE) information within a routing domain. Given the effectiveness of
	these mechanisms, it is convenient to envision using the same		these mechanisms, it is convenient to envision using the same
	mechanism for dissemination of other types of information within the		mechanism for dissemination of other types of information within the
	domain. However, burdening OSPF with this additional information		domain. However, burdening OSPF with this additional information
	will impact intra-domain routing convergence and possibly jeopardize		will impact intra-domain routing convergence and possibly jeopardize
	skipping to change at page 8, line 31 ¶		skipping to change at page 8, line 33 ¶
	This allows the application specific information only to be flooded		This allows the application specific information only to be flooded
	to routers that support the application. A transport instance may		to routers that support the application. A transport instance may
	support multiple topologies as defined in [RFC4915]. But as pointed		support multiple topologies as defined in [RFC4915]. But as pointed
	out in Section 4.5, a transport instance or topology SHOULD NOT		out in Section 4.5, a transport instance or topology SHOULD NOT
	install any IP or IPv6 routes.		install any IP or IPv6 routes.
	Each topology associated with the transport instance MUST be fully		Each topology associated with the transport instance MUST be fully
	connected in order for the LSAs to be successfully flooded to all		connected in order for the LSAs to be successfully flooded to all
	routers in the topology.		routers in the topology.
	5. OSPF Transport Instance Information Encoding		5. OSPF Transport Instance Information (TII) Encoding
	The format of the TLVs within the body of an LSA containing non-		5.1. OSPFv2 Transport Instance Information Encoding
			Application specific information will be flooded in opaque LSAs as
			specified in [RFC5250]. An Opaque LSA option code will be reserved
			for Transport Instance Information (TII) as described in Section 8.
			The TII LSA can be advertised at any of the defined flooding scopes
			(link, area, or autonomous system (AS)).
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| LS age | Options | 9, 10, or 11 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| TBD1 | Opaque ID (Instance ID) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Advertising Router |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| LS sequence number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| LS checksum | length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+- TLVs -+
			| ... |
			g
			OSPFv2 Transport Instance Information Opaque LSA
			The format of the TLVs within the body of an TII LSA is as defined in
			Section 5.3.
			5.2. OSPFv3 Transport Instance Information Encoding
			Application specific information will be flooded in separate LSAs
			with a separate function code. Refer to section A.4.2.1 of
			[RFC5340]. for information on the LS Type encoding in OSPFv3, and
			section 2 of [RFC8362] for OSPFv3 extended LSA types. An OSPFv3
			function code will be reserved for Transport Instance Information
			(TII) as described in Section 8. Same as OSPFv2, the TII LSA can be
			advertised at any of the defined flooding scopes (link, area, or
			autonomous system (AS)). The U bit will be set indicating that
			OSPFv3 TTI LSAs should be flooded even if it is not understood.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| LS age |1|S12| TBD2 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Link State ID (Instance ID) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Advertising Router |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| LS sequence number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| LS checksum | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+- TLVs -+
			| ... |
			OSPFv3 Transport Instance Information LSA
			The format of the TLVs within the body of an TII LSA is as defined in
			Section 5.3.
			5.3. Transport Instance Information (TII) TLV Encoding
			The format of the TLVs within the body of the LSAs containing non-
	routing information is the same as the format used by the Traffic		routing information is the same as the format used by the Traffic
	Engineering Extensions to OSPF [RFC3630]. The LSA payload consists		Engineering Extensions to OSPF [RFC3630]. The LSA payload consists
	of one or more nested Type/Length/Value (TLV) triplets. The format		of one or more nested Type/Length/Value (TLV) triplets. The format
	of each TLV is:		of each TLV is:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value... |		| Value... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Format		TLV Format
	However, each unique application using the mechanisms defined in this		5.3.1. Top-Level TII Application TLV
	document will have it's own unique ID. Whether to encode this ID as
	the top-level TLV or make it part of the OSPF LSA ID is open for
	debate.
	The specific TLVs and sub-TLVs relating to a given application and		An Application top-level TLV will be used to encapsulate application
	the corresponding IANA considerations MUST for standard applications		data advertised within TII LSAs. This top-level TLV may be used to
	MUST be specified in the document corresponding to that application.		handle the local publication/subscription for application specific
			data. The details of such a publication/subscription mechanism are
			beyond the scope of this document. An Application ID is used in the
			top-level application TLV and shares the same code point with IS-IS
			as defined in [RFC6823].
	5.1. OSPFv2 Transport Instance Information Encoding		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 (1) | Length - Variable |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Application ID | Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			. .
			. Sub-TLVs .
			. .
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Application specific information will be flooded in opaque LSAs as		Application ID:
	specified in [RFC5250].		An identifier assigned to this application via the IANA registry,
			as defined in RFC 6823. Each unique application will have a
			unique ID.
	5.2. OSPFv3 Transport Instance Information Encoding		Additional Application-Specific Sub-TLVs:
			Additional information defined by applications can be encoded as
			Sub-TLVs. Definition of such information is beyond the scope of
			this document.
	Application specific information will be flooded in separate LSAs		Top-Level TLV
	with separate function codes. Refer to section A.4.2.1 of [RFC5340].
	for information on the LS Type encoding in OSPFv3, and section 2 of		The specific TLVs and sub-TLVs relating to a given application and
	[RFC8362] for OSPFv3 extended LSA types.		the corresponding IANA considerations MUST be specified in the
			document corresponding to that application.
	6. Manageability Considerations		6. Manageability Considerations
	7. Security Considerations		7. Security Considerations
	The security considerations for the Transport Instance will not be		The security considerations for the Transport Instance will not be
	different for those for OSPFv2 [RFC2328] and OSPFv3 [RFC5340].		different for those for OSPFv2 [RFC2328] and OSPFv3 [RFC5340].
	8. IANA Considerations		8. IANA Considerations
	No IANA actions are required.		8.1. OSPFv2 Opaque LSA Type Assignment
			IANA is requested to assign an option type, TBD1, for Transport
			Instance Information (TII) LSA from the "Opaque Link-State
			Advertisements (LSA) Option Types" registry.
			8.2. OSPFv3 LSA Function Code Assignment
			IANA is requested to assign a function code, TBD2, for Transport
			Instance Information (TII) LSAs from the "OSPFv3 LSA Function Codes"
			registry.
			8.3. OSPF Transport Instance Information Top-Level TLV Registry
			IANA is requested to create a registry for OSPF Transport Instance
			Information (TII) Top-Level TLVs. The first available TLV (1) is
			assigned to the Application TLV Section 5.3.1. The allocation of the
			unsigned 16-bit TLV type are defined in the table below.
			+-------------+-----------------------------------+
			| Range | Assignment Policy |
			+-------------+-----------------------------------+
			| 0 | Reserved (Not to be assigned) |
			| | |
			| 1 | Application TLV |
			| | |
			| 2-16383 | Unassigned (IETF Review) |
			| | |
			| 16383-32767 | Unassigned (FCFS) |
			| | |
			| 32768-32777 | Experimentation (No assignements) |
			| | |
			| 32778-65535 | Reserved (Not to be assigned) |
			+-----------+-------------------------------------+
			TII Top-Level TLV Registry Assignments
	9. Acknowledgement		9. Acknowledgement
			The authors would like to thank Les Ginsberg for review and comments.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
End of changes. 17 change blocks.
	33 lines changed or deleted		161 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/