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]