Internet DRAFT - draft-jaufeerally-nexthop-path-info
draft-jaufeerally-nexthop-path-info
Path Aware Networking Research Group R. Jaufeerally
Internet-Draft AS210036
Intended status: Experimental December 10, 2018
Expires: June 13, 2019
Providing Next External Hop Path Information to End Hosts
draft-jaufeerally-nexthop-path-info-00
Abstract
The aim of this document is to define an interface through which an
Autonomous System (AS) can disseminate information about forwarding
of packets to the next hop outside the AS, to devices within its
network. This information can be used to make path aware routing
decisions, either by being aware of the default route packets will
take when traversing the AS, or by using other mechanisms to control
the path packets which is out of the scope of this document.
Requirements Language
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 [1].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 13, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jaufeerally Expires June 13, 2019 [Page 1]
Internet-Draft panrg-nexthop-path-info December 2018
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Detection of Path Aware Functionality . . . . . . . . . . . . 3
3. The Path Service . . . . . . . . . . . . . . . . . . . . . . 3
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The current state of the internet is such that routing decisions are
made by the network operator, and the end user has no a priori
information about network paths. It is possible to manually find
information about paths a posteriori using tools such as traceroute.
There exists unstandardized out of band mechanisms such as looking
glasses [3] and specialized tools like NLNOG RING [4] that allow for
customizable introspection of the network control and data plane.
These tools provide valuable information to network engineers, and
enthusiastic end users to ascertain information about forwarding
routes which packets are nominally following.
This document defines a standardized interface to provide network
path information to end hosts, routers, and other devices within a
network. This path awareness can be used to optimize use of network
resources by the end host, for example allowing programmatic
decisions on which links to use for a given packet.
The implementation strategy we define is a mechanism to bootstrap
devices within an AS with the information required to obtain path
awareness from the network control plane. In addition, we define a
standard format for the interchange of path information in this
context.
Jaufeerally Expires June 13, 2019 [Page 2]
Internet-Draft panrg-nexthop-path-info December 2018
2. Detection of Path Aware Functionality
In order for an end host to make use of the path aware functionality
in a network, the host needs to detect that the network supports such
features. To make hosts aware of these features we use an extension
to the provisioning domain [2] architecture to advertise a service
which can provide network path information.
We define a new PvD key, "x-52759-pan" which contains information
about the path aware network services. Specifically, in this draft
we use this vehicle to distribute the service endpoint address for
the path resolution service. The PvD contents of this attribute are
defined as follows:
+---------+--------+------------------------------------------------+
| Key | Value | Meaning |
| | type | |
+---------+--------+------------------------------------------------+
| version | string | Which version of the path aware services is |
| | | supported. When implementing this draft the |
| | | string MUST be "draft-irtf-panrg-nexthop-path- |
| | | info-00" |
| url | string | The HTTPS endpoint address of the path service |
+---------+--------+------------------------------------------------+
Table 1: PvD keys
{
"version": "draft-irtf-panrg-nexthop-path-info-00",
"url": "https://path-server.pan.rayhaan.net/"
}
Example contents of the "x-52759-pan" attribute in the PvD JSON
document.
Figure 1
The url parameter MUST be resolvable by the client using the default
name resolution services available in the network, and SHOULD also be
resolvable globally to facilitate usage by hosts using alternative
name resolution services.
3. The Path Service
The Path Service provides a uniform API through which path
information can be obtained. We define in this section the
functionality which this service must provide, and how it will be
accessed by clients.
Jaufeerally Expires June 13, 2019 [Page 3]
Internet-Draft panrg-nexthop-path-info December 2018
+----------------------+--------------------------------------------+
| URL Endpoint | Purpose |
+----------------------+--------------------------------------------+
| /route/<AF>/<prefix> | To get the routes available to the |
| | destination address prefix (<prefix>), |
| | whose type is the provided address family |
| | (<AF>). |
| /route/all | To get all routes reachable in the |
| | network. |
+----------------------+--------------------------------------------+
Table 2: API URL Endpoints
Implementations of this draft MUST support IPv6 as AF parameter, and
MAY also support IPv4.
The data type for returned data in this service is determined by the
HTTP "accept" header which is provided by the client.
Implementations of this draft MUST support the "application/json"
content type and MAY support others which are out of scope of this
document.
When the requested content type is "application/json" the following
schema MUST be used to return data to the client.
{
"dest_prefix": "192.0.2.0/24",
"paths": [{
"id": "0x1",
"link_name": "prov-1",
"AS_Path": [64496, 64497, 64498]
},
{
"id": "0x2",
"link_name": "IX-CH",
"AS_Path": [64496, 64498]
}
]
}
Figure 2
When all the routes are requested the format of data returned is as
follows.
Jaufeerally Expires June 13, 2019 [Page 4]
Internet-Draft panrg-nexthop-path-info December 2018
{
"links": [
{
"id": "0x1",
"link_name": "prov-1",
"routes": [
{
"prefix": "192.0.2.0/24",
"AS_Path": [64496, 64497, 64498]
}
]
},
{
"id": "0x2",
"link_name": "IX-CH",
"routes": [
{
"prefix": "192.0.2.0/24",
"AS_Path": [64496, 64498]
}
]
}
]
}
Additionally a diff since a certain timestamp MAY be provided by an
implementation of this draft. Implementations that chose to provide
this functionality MUST do so by accepting the "since" query
parameter on the "/route/all" URL with a timestamp of seconds since
January 1, 1970. The server will then return routes which have been
added and / or removed since the specified timestamp. The format is
the same as the full route schema, except for two additional fields,
as specified below.
The objects contained within the "links" array MAY contain a "delta"
key which MUST be either "add" or "del". This means the link was
added or removed since the requested "since" time respectively.
Furthermore individual route objects contained within the "routes"
key MUST contain a "delta" key which MUST be either "add" or "del" if
the route has been added or removed over that link respectively. If
a route has not changed it MUST NOT be included in the diff message.
4. Acknowledgements
The authors would like to thank Brian Trammell and Milan Pandurov for
their valuable input and feedback.
Jaufeerally Expires June 13, 2019 [Page 5]
Internet-Draft panrg-nexthop-path-info December 2018
5. IANA Considerations
IANA is asked to allocate a new string in the registry entitled
"Additional Information PvD Keys" for use in the provisioning domain
additional information JSON document.
6. Security Considerations
The explicit knowledge of paths within a network by end devices is
not considered a security risk, since this information can be
obtained through other mechanisms, albeit less reliably and in a non
uniform manner. Moreover, should a service provider not wish to
reveal the existence of a link, there is no obligation to provide
such information in the data returned, however the authors believe
having more transparency in the network is better for the ecosystem
as a whole.
This internet draft does not specify any security mechanisms for
ensuring the authenticity of information returned from the route
service, but such a mechanism may be proposed at a later point in
time.
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://xml.resource.org/public/rfc/html/rfc2119.html>.
[2] Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
draft-ietf-intarea-provisioning-domains-03 (work in
progress), October 2018.
7.2. Informative References
[3] Hurricane Electric Internet Services, "Hurricane Electric
Looking Glass", 2018, <https://lg.he.net/>.
[4] Netherlands Network Operator Group, "NLNOG RING", 2018,
<https://ring.nlnog.net/>.
Author's Address
Jaufeerally Expires June 13, 2019 [Page 6]
Internet-Draft panrg-nexthop-path-info December 2018
Rayhaan Jaufeerally
AS210036
Swiss Post Box 1610
Kasernenstasse 97
Zuerich 1 8021
CH
Phone: +41 22 518 16 29
Email: ietf@rayhaan.ch
URI: https://rayhaan.ch/
Jaufeerally Expires June 13, 2019 [Page 7]
