< draft-irtf-panrg-questions-11.txt		draft-irtf-panrg-questions-12.txt >
	Path Aware Networking RG B. Trammell		Path Aware Networking RG B. Trammell
	Internet-Draft Google Switzerland GmbH		Internet-Draft Google Switzerland GmbH
	Intended status: Informational 11 November 2021		Intended status: Informational 25 January 2022
	Expires: 15 May 2022		Expires: 29 July 2022
	Current Open Questions in Path Aware Networking		Current Open Questions in Path Aware Networking
	draft-irtf-panrg-questions-11		draft-irtf-panrg-questions-12
	Abstract		Abstract
	In contrast to the present Internet architecture, a path-aware		In contrast to the present Internet architecture, a path-aware
	internetworking architecture has two important properties: it exposes		internetworking architecture has two important properties: it exposes
	the properties of available Internet paths to endpoints, and provides		the properties of available Internet paths to endpoints, and provides
	for endpoints and applications to use these properties to select		for endpoints and applications to use these properties to select
	paths through the Internet for their traffic. While this property of		paths through the Internet for their traffic. While this property of
	"path awareness" already exists in many Internet-connected networks		"path awareness" already exists in many Internet-connected networks
	within single domains and via administrative interfaces to the		within single domains and via administrative interfaces to the
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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 15 May 2022.		This Internet-Draft will expire on 29 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction to Path-Aware Networking . . . . . . . . . . . . 2		1. Introduction to Path-Aware Networking . . . . . . . . . . . . 2
	1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. A Vocabulary of Path Properties . . . . . . . . . . . . . 5		2.1. A Vocabulary of Path Properties . . . . . . . . . . . . . 5
	2.2. Discovery, Distribution, and Trustworthiness of Path		2.2. Discovery, Distribution, and Trustworthiness of Path
	Properties . . . . . . . . . . . . . . . . . . . . . . . 5		Properties . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Supporting Path Selection . . . . . . . . . . . . . . . . 6		2.3. Supporting Path Selection . . . . . . . . . . . . . . . . 6
	2.4. Interfaces for Path Awareness . . . . . . . . . . . . . . 6		2.4. Interfaces for Path Awareness . . . . . . . . . . . . . . 6
	2.5. Implications of Path Awareness for the Transport and		2.5. Implications of Path Awareness for the Transport and
	Application Layers . . . . . . . . . . . . . . . . . . . 7		Application Layers . . . . . . . . . . . . . . . . . . . 7
	2.6. What is an Endpoint? . . . . . . . . . . . . . . . . . . 7		2.6. What is an Endpoint? . . . . . . . . . . . . . . . . . . 7
	2.7. Operating a Path Aware Network . . . . . . . . . . . . . 8		2.7. Operating a Path Aware Network . . . . . . . . . . . . . 8
	2.8. Deploying a Path Aware Network . . . . . . . . . . . . . 9		2.8. Deploying a Path Aware Network . . . . . . . . . . . . . 8
	3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	4. Informative References . . . . . . . . . . . . . . . . . . . 10		4. Informative References . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction to Path-Aware Networking		1. Introduction to Path-Aware Networking
	In the current Internet architecture, the network layer provides an		In the current Internet architecture, the network layer provides a
	unverifiable, best-effort service to the endpoints using it. While		best-effort service to the endpoints using it, without verifiability
	there are technologies that attempt better-than-best-effort delivery,		of the properties of the path between tne endpoints. While there are
	the interfaces to these are generally administrative as opposed to		network layer technologies that attempt better-than-best-effort
	endpoint-exposed (e.g. Path Computation Element (PCE) [RFC4655] and		delivery, the interfaces to these are generally administrative as
	Software-Defined Wide Area Network (SD-WAN) approaches), and they are		opposed to endpoint-exposed (e.g. Path Computation Element (PCE)
	often restricted to single administrative domains. In this
	environment, an application can assume that a packet with a given		[RFC4655] and Software-Defined Wide Area Network (SD-WAN)
	destination address will eventually be forwarded toward that		approaches), and they are often restricted to single administrative
	destination, but little else.		domains. In this architecture, an application can assume that a
			packet with a given destination address will eventually be forwarded
			toward that destination, but little else.
	A transport layer protocol such as TCP can provide reliability over		A transport layer protocol such as TCP can provide reliability over
	this best-effort service, and a protocol above the network layer such		this best-effort service, and a protocol above the network layer,
	as IPsec Authentication Header (AH) [RFC4302] or Transport Layer		such as Transport Layer Security (TLS) [RFC8446] can authenticate the
	Security (TLS) [RFC8446] can authenticate the remote endpoint.		remote endpoint. However, little, if any, explicit information about
	However, little, if any, explicit information about the path is		the path is available to the endpoints, and any assumptions made
	available to the endpoint, and assumptions about that path often do		about that path often do not hold. These sometimes have serious
	not hold, sometimes with serious impacts on the application, as in		impacts on the application, as in the case with BGP hijacking
	the case with BGP hijacking attacks.		attacks.
	By contrast, in a path-aware internetworking architecture, endpoints		By contrast, in a path-aware internetworking architecture, endpoints
	have the ability to select or influence the path through the network		can select or influence the path(s) through the network used by any
	used by any given packet or flow. The network and transport layers		given packet or flow. The network and transport layers explicitly
	explicitly expose information about the path or paths available from		expose information about the path or paths available to the endpoints
	one endpoint to another, and to those endpoints and the applications		and to the applications running on them, so that they can make this
	running on them, so that they can make this selection. The		selection. The Application Layer Traffic Optimization (ALTO)
	Application Layer Traffic Optimization (ALTO) protocol [RFC7285] can		protocol [RFC7285] can be seen as an example of a path-awareness
	be seen as an example of a path-awareness approach implemented in		approach implemented in transport-layer terms on the present Internet
	transport-layer terms on the present Internet protocol stack.		protocol stack.
	Path selection provides explicit visibility and control of network		Path selection provides explicit visibility and control of network
	treatment to applications and users of the network. This selection		treatment to applications and users of the network. This selection
	is available to the application, transport, and/or network layer		is available to the application, transport, and/or network layer
	entities at each endpoint. Path control at the flow and subflow		entities at each endpoint. Path control at the flow and subflow
	level enables the design of new transport protocols that can leverage		level enables the design of new transport protocols that can leverage
	multipath connectivity across disjoint paths through the Internet,		multipath connectivity across disjoint paths through the Internet,
	even over a single physical interface. When exposed to applications,		even over a single physical interface. When exposed to applications,
	or to end-users through a system configuration interface, path		or to end-users through a system configuration interface, path
	control allows the specification of constraints on the paths that		control allows the specification of constraints on the paths that
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 11 ¶
	internetworking seeks to extend this awareness across domain		internetworking seeks to extend this awareness across domain
	boundaries without resorting to overlays, except as a transition		boundaries without resorting to overlays, except as a transition
	technology.		technology.
	This document presents a snapshot of open questions in this space		This document presents a snapshot of open questions in this space
	that will need to be answered in order to realize a path-aware		that will need to be answered in order to realize a path-aware
	internetworking architecture; it is published to further frame		internetworking architecture; it is published to further frame
	discussions within and outside the Path Aware Networking Research		discussions within and outside the Path Aware Networking Research
	Group, and is published with the rough consensus of that group.		Group, and is published with the rough consensus of that group.
	1.1. Definition		1.1. Definitions
	For purposes of this document, "path aware networking" describes		For purposes of this document, "path aware networking" describes
	endpoint discovery of the properties of paths they use for		endpoint discovery of the properties of paths they use for
	communication across an internetwork, and endpoint reaction to these		communication across an internetwork, and endpoint reaction to these
	properties that affects routing and/or data transfer. Note that this		properties that affects routing and/or data transfer. Note that this
	can and already does happen to some extent in the current Internet		can and already does happen to some extent in the current Internet
	architecture; this definition expands current techniques of path		architecture; this definition expands current techniques of path
	discovery and manipulation to cross administrative domain boundaries		discovery and manipulation to cross administrative domain boundaries
	and up to the transport and application layers at the endpoints.		and up to the transport and application layers at the endpoints.
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	which enable this discovery and selection.		which enable this discovery and selection.
	A "path", for the purposes of these definitions, is abstractly		A "path", for the purposes of these definitions, is abstractly
	defined as a sequence of adjacent path elements over which a packet		defined as a sequence of adjacent path elements over which a packet
	can be transmitted, where the definition of "path element" is		can be transmitted, where the definition of "path element" is
	technology-dependent. As this document is intended to pose questions		technology-dependent. As this document is intended to pose questions
	rather than answer them, it assumes that this definition will be		rather than answer them, it assumes that this definition will be
	refined as part of the answer the first two questions it poses, about		refined as part of the answer the first two questions it poses, about
	the vocabulary of path properties and how they are disseminated.		the vocabulary of path properties and how they are disseminated.
	Research into path aware networking covers any and all aspects of		Research into path aware internetworking covers any and all aspects
	designing, building, and operating path aware internetworks or the		of designing, building, and operating path aware internetworks or the
	networks and endpoints attached to them. This document presents a		networks and endpoints attached to them. This document presents a
	collection of research questions to address in order to make a path		collection of research questions to address in order to make a path
	aware Internet a reality.		aware Internet a reality.
	2. Questions		2. Questions
	Realizing path-aware networking requires answers to a set of open		Realizing path-aware networking requires answers to a set of open
	research questions. This document poses these questions, as a		research questions. This document poses these questions, as a
	starting point for discussions about how to realize path awareness in		starting point for discussions about how to realize path awareness in
	the Internet, and to direct future research efforts within the Path		the Internet, and to direct future research efforts within the Path
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 21 ¶
	and for the endpoint to make use of that information, it is necessary		and for the endpoint to make use of that information, it is necessary
	to define a common vocabulary for paths through an internetwork, and		to define a common vocabulary for paths through an internetwork, and
	properties of those paths. The elements of this vocabulary could		properties of those paths. The elements of this vocabulary could
	include terminology for components of a path and properties defined		include terminology for components of a path and properties defined
	for these components, for the entire path, or for subpaths of a path.		for these components, for the entire path, or for subpaths of a path.
	These properties may be relatively static, such as the presence of a		These properties may be relatively static, such as the presence of a
	given node or service function on the path; as well as relatively		given node or service function on the path; as well as relatively
	dynamic, such as the current values of metrics such as loss and		dynamic, such as the current values of metrics such as loss and
	latency.		latency.
	This vocabulary must be defined carefully, as its design will have		This vocabulary and its representation must be defined carefully, as
	impacts on the expressiveness of a given path-aware internetworking		its design will have impacts on the properties (e.g., expressiveness,
	architecture. This expressiveness also exhibits tradeoffs. For		scalability, security) of a given path-aware internetworking
	example, a system that exposes node-level information for the		architecture. For example, a system that exposes node-level
	topology through each network would maximize information about the		information for the topology through each network would maximize
	individual components of the path at the endpoints, at the expense of		information about the individual components of the path at the
	making internal network topology universally public, which may be in		endpoints, at the expense of making internal network topology
	conflict with the business goals of each network's operator.		universally public, which may be in conflict with the business goals
	Furthermore, properties related to individual components of the path		of each network's operator. Furthermore, properties related to
	may change frequently and may quickly become outdated. However,		individual components of the path may change frequently and may
	aggregating the properties of individual components to distill end-		quickly become outdated. However, aggregating the properties of
	to-end properties for the entire path is not trivial.		individual components to distill end-to-end properties for the entire
			path is not trivial.
	2.2. Discovery, Distribution, and Trustworthiness of Path Properties		2.2. Discovery, Distribution, and Trustworthiness of Path Properties
	The second question: how do endpoints and applications get access to		The second question: how do endpoints and applications get access to
	accurate, useful, and trustworthy path properties?		accurate, useful, and trustworthy path properties?
	Once endpoints and networks have a shared vocabulary for expressing		Once endpoints and networks have a shared vocabulary for expressing
	path properties, the network must have some method for distributing		path properties, the network must have some method for distributing
	those path properties to the endpoint. Regardless of how path		those path properties to the endpoints. Regardless of how path
	property information is distributed to the endpoints, the endpoints		property information is distributed, the endpoints require a method
	require a method to authenticate the properties -- to determine that		to authenticate the properties -- to determine that they originated
	they originated from and pertain to the path that they purport to.		from and pertain to the path that they purport to.
	Choices in distribution and authentication methods will have impacts		Choices in distribution and authentication methods will have impacts
	on the scalability of a path-aware architecture. Possible dimensions		on the scalability of a path-aware architecture. Possible dimensions
	in the space of distribution methods include in-band versus out-of-		in the space of distribution methods include in-band versus out-of-
	band, push versus pull versus publish-subscribe, and so on. There		band, push versus pull versus publish-subscribe, and so on. There
	are temporal issues with path property dissemination as well,		are temporal issues with path property dissemination as well,
	especially with dynamic properties, since the measurement or		especially with dynamic properties, since the measurement or
	elicitation of dynamic properties may be outdated by the time that		elicitation of dynamic properties may be outdated by the time that
	information is available at the endpoints, and interactions between		information is available at the endpoints, and interactions between
	the measurement and dissemination delay may exhibit pathological		the measurement and dissemination delay may exhibit pathological
	skipping to change at page 10, line 10 ¶		skipping to change at page 9, line 42 ¶
	explicitly radiates more information about the network's deployment		explicitly radiates more information about the network's deployment
	and configuration, and implicitly radiates information about endpoint		and configuration, and implicitly radiates information about endpoint
	configuration and preference through path selection, must also be		configuration and preference through path selection, must also be
	addressed.		addressed.
	3. Acknowledgments		3. Acknowledgments
	Many thanks to Adrian Perrig, Jean-Pierre Smith, Mirja Kuehlewind,		Many thanks to Adrian Perrig, Jean-Pierre Smith, Mirja Kuehlewind,
	Olivier Bonaventure, Martin Thomson, Shwetha Bhandari, Chris Wood,		Olivier Bonaventure, Martin Thomson, Shwetha Bhandari, Chris Wood,
	Lee Howard, Mohamed Boucadair, Thorben Krueger, Gorry Fairhurst,		Lee Howard, Mohamed Boucadair, Thorben Krueger, Gorry Fairhurst,
	Spencer Dawkins, Theresa Enghardt, Laurent Ciavaglia, and Stephen		Spencer Dawkins, Reese Enghardt, Laurent Ciavaglia, Stephen Farrell,
	Farrell, for discussions leading to questions in this document, and		and Richard Yang, for discussions leading to questions in this
	for feedback on the document itself.		document, and for feedback on the document itself.
	This work is partially supported by the European Commission under		This work is partially supported by the European Commission under
	Horizon 2020 grant agreement no. 688421 Measurement and Architecture		Horizon 2020 grant agreement no. 688421 Measurement and Architecture
	for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat		for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat
	for Education, Research, and Innovation under contract no. 15.0268.		for Education, Research, and Innovation under contract no. 15.0268.
	This support does not imply endorsement.		This support does not imply endorsement.
	4. Informative References		4. Informative References
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	DOI 10.17487/RFC4302, December 2005,
	<https://www.rfc-editor.org/rfc/rfc4302>.
	[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path		[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
	Computation Element (PCE)-Based Architecture", RFC 4655,		Computation Element (PCE)-Based Architecture", RFC 4655,
	DOI 10.17487/RFC4655, August 2006,		DOI 10.17487/RFC4655, August 2006,
	<https://www.rfc-editor.org/rfc/rfc4655>.		<https://www.rfc-editor.org/rfc/rfc4655>.
	[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,		[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
	Previdi, S., Roome, W., Shalunov, S., and R. Woundy,		Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
	"Application-Layer Traffic Optimization (ALTO) Protocol",		"Application-Layer Traffic Optimization (ALTO) Protocol",
	RFC 7285, DOI 10.17487/RFC7285, September 2014,		RFC 7285, DOI 10.17487/RFC7285, September 2014,
	<https://www.rfc-editor.org/rfc/rfc7285>.		<https://www.rfc-editor.org/rfc/rfc7285>.
End of changes. 17 change blocks.
	63 lines changed or deleted		62 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/