Subject: [alto] Review of draft-ietf-alto-path-vector-00

From: Shenshen Chen <[email-masked]>
Date: Wed, 28 Jun 2017 22:53:49 +0800

Dear authors of alto-path-vector and all,

After reviewing this draft, I have two comments:

1. To avoid confusion, I suggest replacing every network element (NE) by
network abstract element (ANE), since every network element in this draft
is "abstract" network element.
   An alternative solution is to remove ANE. The network element is
"abstract" according to the definition in Wikipedia ("A network element
is usually defined as a manageable logical entity uniting one or more
physical devices."), which makes it redundant to emphasize "abstract" so
many times.

2. The title of section 4.4 should be "Query-specific Attribute", which
is the noun this section introduced. And the title of section 6.4 should
be "Filtered Cost Map Example" corresponding to section 5.8.

Here is a list of typos (comments are marked with ">>>"):

[Page 3]
     5.8.  Filtered Cost Map Extensions  . . . . . . . . . . . . . .  12
       5.8.1.  Capabilities  . . . . . . . . . . . . . . . . . . . .  12
       5.8.2.  Accept Input Parameters . . . . . . . . . . . . . . .  13
       5.8.3.  Propertymap . . . . . . . . . . . . . . . . . . . . .  14
       5.8.4.  Response  . . . . . . . . . . . . . . . . . . . . . .  14
     5.9.  Endpoint Cost Service Extensions  . . . . . . . . . . . .  14
       5.9.1.  Capabilities  . . . . . . . . . . . . . . . . . . . .  15
       5.9.2.  Accept Input Parameters . . . . . . . . . . . . . . .  15

>>> Accept Input Parameters => Acceptable Input Parameters

[Page 3]
 7.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . .  25

[Page 25]
 7.  Compatibility

>>> Compatibility => Compatibility Considerations/Compatibilities

[Page 4, 5]
   The document is organized as follows.  Section 3 gives an example of
   flow scheduling to illustrate the need to introduce cost mode "path-
   vector" and cost metric "ane".  Section 4 gives an overview of the
   path-vector extension.  Section 5 specifies the new cost mode and
   cost metric, new domain type, entity properties and protocol
   extensions for (Filtered) Cost Maps and Endpoint Cost Services.
   Section 6 presents several examples.  Section 7 discusses the
   compatibility issues with some other proposed ALTO extensions.
   Section 8 discusses the time to live problem.  Section 9 discusses
   several design decisions.  Section 10 and Section 11 discusses about

>>> discusses about => discusses

   security and IANA Considerations.

2.  Terminology

   This document uses the following terms: Network Element, Network
   Element Name, Network Element Property, Network Element Property Map
   and Path Vector.

   o  Network Element (NE): A Network Element is an abstract network
      element, which can be a link, a network switching device, or a set
      of devices.

   o  Network Element Name (NEN): The id of a NE.  It can be referenced

>>> a NE => an NE (which pronounced as [ɛn'iː])

      by Cost Map, Filtered Cost Map, Endpoint Cost Service and Property
      Map.

   o  Network Element Property (NEP): The property of a NE.  It can be
      the available bandwidth of a link, the delay or other available
      properties.

[Page 10]
5.4.2.  Domain-Specific Entity Addresses

   The entity address of ane domain is encoded as a JSON string.  The
   string MUST be no more than 64 characters, and it MUST NOT contain
   characters other than US-ASCII alphanumeric characters
   (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-',
   U+002D), the colon (':', U+003A), the at sign ('@', code point
   U+0040), the low line ('_', U+005F), or the '.' separator (U+002E).
   The '.' separator is reserved for future use and MUST NOT be used
   unless specifically indicated in this document, or an extension

>>> delete the comma before "or" (since there're only two items in a series)
   document.

[Page 16]
6.1.  Workflow

   o  Send the GET request for the whole Information Resource Directory.

   o  Look for the resource of the (Filtered) Cost Map/Endpoint Cost
      Service which contains the path-vector cost type and get the

>>> get => gets

      resource id of the property map.

[Page 20]
6.4.  Multi-Cost Filtered Cost Map Example

   The following example presents the request and response of "filtered-
   multi-cost-map".  In this example, the client is interested in the
   path-vector and numerical routing cost information.  The client uses
   "or-constraints" but all the results satisfy the conditions.  In
   resposne, the extended "vtag" field is included in "meta" to provide

[Page 22]
6.5.  Endpoint Cost Service Example

   If the ALTO client expects the routing state information between
   endpoints, it can also query the "default-endpoint-cost-map" resource
   which supports path vector.  In resposne, the extended "vtag" field

>>> resposne => response

[Page 23]
6.6.  Network Element Property Map Example # 1

   After the client send the query to the Multi-Cost Filtered Cost Map
   "filtered-multi-cost-map" and get the response with query-id "query1"
   (See Section 6.4).  The client send request to the "ane-property-map-

[Page 24]
6.7.  Network Element Property Map Example # 2

   After the client send the query to the Endpoint Cost Service
   "default-endpoint-cost-map" and get the response with query-id
   "query2" (See Section 6.5).  The client send request to the "ane-

>>> The client send => The client sends

[Page 27]
9.3.  Snapshot and real-time update

   As the suggested workflow mentioned in Section 6.1, the properties of
   the abstract network elements are computed ahead of the query of
   these properties.  So the properties of abstract network elements are
   likely to be snapshot rather than realt-time value when queried.

>>> (a) snapshot, (a) real-time value, realt-time => real-time

10.  Security Considerations

   We can identify multiple potential security issues.  A main security

>>> A main => The main

   issue is network privacy, as the path-vector information may reveal
   more network internal structures than the more abstract single-node
   abstraction.  The network should consider protection mechanisms to
   reduce information exposure, in particular, in settings where the
   network and the application do not belong to the same trust domain.
   On the other hand, in a setting of the same trust domain, a key
   benefit of the path-vector abstraction is reduced information
   transfer from the network to the application.

Best Regards,
Shenshen