An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector
draft-ietf-alto-path-vector-25

[Ballot comment]
A huge thanks to all involved for the quick turnaround in updating this
document and getting draft-bw-alto-cost-mode in place to help
rationalize the IANA registry situation across the ALTO documents!  I'm
sorry that my turnaround time here was not so quick.

Fortunately, I can report that the changes address my previous Discuss
concern and comments, and I have just one additional comment, in Section 6.5.2:

  The cost mode "array" indicates that every cost value in the response
  body of a (Filtered) Cost Map or an Endpoint Cost Service MUST be
  interpreted as a JSON array object.  This cost mode can be applied to
  all cost metrics.

Would it be accurate to say that "additional specifications will be
needed to clarify the semantics of the array cost mode when combined
with path metrics other than 'ane-path'"?
That is to say, I do agree that the cost mode should be applicable to
all cost metrics, but I'm not sure if the current specifications are
unambiguous about what it means to have an array of ordinal, for
example.

[Ballot comment]
-22 to -24 should resolve discuss

A huge thanks to all involved for the quick turnaround in updating this
document and getting draft-bw-alto-cost-mode in place to help
rationalize the IANA registry situation across the ALTO documents!  I'm
sorry that my turnaround time here was not so quick.

Fortunately, I can report that the changes address my previous Discuss
concern and comments, and I have just one additional comment, in Section 6.5.2:

  The cost mode "array" indicates that every cost value in the response
  body of a (Filtered) Cost Map or an Endpoint Cost Service MUST be
  interpreted as a JSON array object.  This cost mode can be applied to
  all cost metrics.

Would it be accurate to say that "additional specifications will be
needed to clarify the semantics of the array cost mode when combined
with path metrics other than 'ane-path'"?
That is to say, I do agree that the cost mode should be applicable to
all cost metrics, but I'm not sure if the current specifications are
unambiguous about what it means to have an array of ordinal, for
example.

[Ballot discuss]
The IANA Considerations section seems incomplete.
Looking over the registries at
https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml and
comparing against the mechanisms defined in this document, it seems that
we need to register the "ane-path" Cost Metric.  More worryingly, there is
no registry on that page in which the "array" cost mode could be
registered, and it seems that using any value other than "numerical" or
"ordinal" would violate a "MUST" in §10.5 of RFC 7285.  This seems to
present some procedural difficulties, especially now that this document is
targeting Experimental status rather than Proposed Standard (which, to be
clear, I think was the right thing to do).

[Ballot comment]
Thanks for fleshing out the security considerations section substantially
in recent revisions, and thanks to Sam Weiler for the multiple secdir
reviews.  While I agree with Sam that it would be nice to be able to list
examples of non-DRM technical measures to protect the confidentiality of
sensitive path vector information, I can't actually think of any that
would be worth listing, myself.  So we may have to proceed with the
current text (unless you have further ideas, of course).

It looks like the VersionTag.tag value of "d827f484cb66ce6df6b5077cb8562b0a"
is used in a few different examples.  While being associated with
different VersionTag.ResourceID values is sufficient to distinguish the
uses from each other, it seems like these examples might be more
enlightening if distinct VersionTag.tag values were used for the distinct
resources.

Section 1

  Predicting such information can be very complex without the help of
  ISPs [BOXOPT].  [...]

I'm not entirely sure which part(s) of [BOXOPT] are being referenced here.
Their scheme seems to involve producing a privacy-preserving scheme for
resource allocation that does involve exchnages between client and
network, just not ones that reveal sensitive information.  Did I miss a
part where they compare against a scenario where the network/ISP does not
provide input?  (I only skimmed the paper.)

Section 4.1

  *  The ALTO server must expose abstract information on the properties
      of the ANEs used by "eh1 -> eh2" and "eh1 -> eh4", e.g., the
      available bandwidth between "eh1 - sw1", "sw1 - sw5", "sw5 - sw7",
      "sw5 - sw6", "sw6 - sw7", "sw7 - sw2", "sw7 - sw4", "sw2 - eh2",
      "sw4 - eh4" in Case 1.

Does it actually need to expose exactly the available bandwidth between
all those listed pairs of entities?  I would have thought that some of the
details could be abstracted away.

Section 4.2.1

                                    For example, assume hosts "a", "b",
  "c" are in site 1 and hosts "d", "e", "f" are in site 2, and there

In Figure 5, I see something that looks like an entry for [d] in the "Site
1" part, and an entry for [c] in the "Site 2" part.  I'm not sure if
that's just an attempt to indicate the directionality of the core backbone
or something else.

Section 6.4

  Note that these property types do not depend on any information
  resource.  As such, their ResourceID part must be empty.

Does this mean that the '.' is absent as well?

Section 6.5.2

  Note that this cost mode only requires the cost value to be a JSON
  array of JSONValue.  However, an ALTO server that enables this
  extension MUST return a JSON array of ANEName (Section 6.1) when the
  cost metric is "ane-path".

If we're going to require that the cost mode "array" only be used with an
array of ANEName, then would it make more sense to call the cost mode
"anearray", leaving the generic "array" for a more generic behavior?

Section 6.6

  DOMAIN-NAME:  DOMAIN-NAME has the same format as dot-atom-text
      specified in Section 3.2.3 of [RFC5322].  It must be the domain
      name of the ALTO server.

(somewhat editorial) is there always exactly one domain name of the ALTO
server (vs. more than one)?

Section 7.2.4

  object {
    [EntityPropertyName ane-property-names<0..*>;]
  } PVFilteredCostMapCapabilities : FilteredCostMapCapabilities;

  with fields:

Up in §7.2.3 we didn't repeat any of the fields from the base type we
inherited from.  Here we do, but (apparently) only because we have more to
say about them, e.g., new restrictions on the cost-type-names field to
include the Path Vector cost type.  Do we want to mention that some fields
are repeated because we make their definiton more specific for the
PVFilteredCostMapCapabilities usage?

Also, since we're repeating most of the FilteredCostMapCapabilities
fields, is it worth also defining max-cost-types for completeness?

Section 7.2.6

  The "Content-Type" header of the response MUST be "multipart/related"
  as defined by [RFC2387] with the following parameters:

This could be read as saying that all three parameters are mandatory, but
the actual description for "start" includes the phrase "if present",
implying that it is optional.  Some more clarity would be helpful
(especially relating to whether "boundary" is optional or mandatory, which
RFC 2387 itself does not actually clarify directly).

  *  The Path Vector part MUST include "Content-ID" and "Content-Type"
      [...]
      RESOURCE-ID in the "Content-ID" of the Path Vector part.  The
      "meta" field MUST also include the "dependent-vtags" field, whose
      value is a single-element array to indicate the version tag of the
      network map used, where the network map is specified in the "uses"
      attribute of the multipart Filtered Cost Map resource in IRD.

Just to confirm, there would not be a need to include in this
"dependent-vtags" field any dependent resources relating to persistent
ANEs?

      Vector part MUST be included in the "dependent-vtags".  If
      "persistent-entity-id" is requested, the version tags of the
      dependent resources that MAY expose the entities in the response
      MUST also be included.

This seems a surprising use of the normative MAY, to me.

  HTTP/1.1 200 OK
  Content-Length: 821
  Content-Type: multipart/related; boundary=example-1;

I'm having a hard time reproducing this Content-Length value.  Could you
double-check it?

Section 7.3.3

  POST /ecs/pv HTTP/1.1
  Host: alto.example.com
  Accept: multipart/related;type=application/alto-endpointcost+json,
          application/alto-error+json
  Content-Length: 222

I'm getting a length of 226 or 227 (depending on newline at end of file);
please confirm that 222 is correct.

Section 7.3.6

  boundary:  The boundary parameter is as defined in [RFC2387].

As I alluded to above, the boundary parameter is actually defined in RFC
2045; the only appearance in RFC 2387 is in two examples.

      The body of the Path Vector part MUST be a JSON object with the
      same format as defined in Section 11.5.1.6 of [RFC7285] when the
      "cost-type" field is present in the input parameters and MUST be a
      JSON object with the same format as defined in Section 4.1.3 of
      [RFC8189] if the "multi-cost-types" field is present.  The JSON

I think §4.2.3 of RFC 8189 is somewhat more relevant than §4.1.3, here.

      The body of the Unified Property Map part MUST be a JSON object
      with the same format as defined in Section 4.6 of
      [I-D.ietf-alto-unified-props-new].  [...]

Is §4.6 the right reference here?  I don't see much defining a JSON format
in that section or subsections.

      Vector part MUST be included in the "dependent-vtags".  If
      "persistent-entity-id" is requested, the version tags of the
      dependent resources that MAY expose the entities in the response
      MUST also be included.

As above, this is an unusual use of the normative "MAY".

  HTTP/1.1 200 OK
  Content-Length: 810
  Content-Type: multipart/related; boundary=example-1;
                type=application/alto-endpointcost+json

Continuing the theme, please check this Content-Length as well.

Section 8.4

  As mentioned in Section 6.5.1, an advanced ALTO server may obfuscate
  the response in order to preserve its own privacy or conform to its
  own policies.  [...]

Is §6.5.1 the correct reference?  The word "obfuscate" does not appear
therein that I can see.

Section 8.5

Is there anything to say about updates needing to be paired in the same
way/for the same reasons we have to use multipart/related to get a
consistent picture of the path vector cost map and its associated ANE
property map?  Or perhaps in §9.3 instead?

Section 8.6

  The second part is the same as in Section 8.4

It seems only analogous, not "the same as", to me -- this example uses
aggregated ANEs but §8.3 used the full topology of Figure 10.

    "endpoint-cost-map": {
      "ipv4:192.0.2.34": {
        "ipv4:192.0.2.2":  [[ "NET3", "AGGR1" ], 1],
        "ipv4:192.0.2.50":  [[ "NET3", "AGGR2" ], 1]
      },
      "ipv6:2001:db8::3:1": {
        "ipv6:2001:db8::4:1": [[ "NET3", "AGGR2" ], 1]

Is it really plausible to use the same routing cost of 1 for all three
paths?

Section 11

Streaming updates of max-reservable-bandwidth seems to provide basically
an equivalent information stream as to what paths have been reserved (and
their bandwidth).  That information might be differently sensitive than
the primary network information we're exposing with the path-vector
methodology, so we should probably mention this "information leakage"
channel and give some guidance about what server behaviors might mitigate
the leakage (e.g., batching updates, though I suspect that the policy for
doing so in a way that minimizes information leakage will be about as hard
a problem to solve as padding policies are in general).

I'm a little surprised that we didn't mention anything about persistent
ANEs here (which would be a great way to contrast with the obfuscation
that ephemeral ANEs provide).

MIME parsers have historically been a recurring source of
security-relevant bugs in other contexts.  Perhaps that's sufficiently
well known to not need restating here, though.

  For risk type (3), an ALTO server MUST use dynamic mappings from
  ephemeral ANE names to underlying physical entities.  Thus, ANE names
  contained in the Path Vector responses to different clients or even
  for different request from the same client SHOULD point to different
  physical entities.  [...]

The guidance of "SHOULD point to different physical entities" doesn't seem
quite right.  If the ANE abstraction actually attempted to maximize the
number of distinct physical entities represented, that seems lke it would
make graph reconstruction easier, rather than harder.  Perhaps it is
better to give guidance about noncorrelation over time of the ANE
name/physical element mapping, or even guidance to just use randomized ANE
names.

Section 13.1

I don't think RFC 4271 needs to be classified as normative; we seem to
only reference it as an analogy for the Path Vector/AS Path.

Section 13.2

  [BOXOPT]  Xiang, Q., Yu, H., Aspnes, J., Le, F., Kong, L., and Y.R.
              Yang, "Optimizing in the dark: Learning an optimal
              solution through a simple request interface", Proceedings
              of the AAAI Conference on Artificial Intelligence 33,
              1674-1681 , 2019.

It looks like this is https://doi.org/10.1609/aaai.v33i01.33011674 ; if
so, including the DOI link would be very helpful for readers.

That's just the one I happend to go pull up; DOIs for the other papers (if
available) should be included, too.

NITS

Section 1

  Map that contains the properties requested for these ANEs.  To
  enforce consistency and improve server scalability, this document
  uses the "multipart/related" message defined in [RFC2387] to return
  the two maps in a single response.

I think it's more typical to say "content type" than "message" in this
context.

Section 3

      performance of traffic.  An ANE can be a physical device such as a
      router, a link or an interface, or an aggregation of devices such
      as a subnetwork, or a data center.

I think we do not want a comma before "or a data center", since the data
center is just another example of an aggregation of devices.

Section 4.1

  performance.  The capacity region information for those flows will
  benefit the scheduling.  However, Cost Maps as defined in [RFC7285]
  can not reveal such information.

I'm not sure I know what "capacity region information" is; did we mean
"region capacity information" (or maybe "Knowledge of the relevant
capacity regions for those flows")?

  With the ALTO Cost Map, the cost between PID1 and PID2 and between
  PID1 and PID4 will be 100 Mbps.  The client can get a capacity region

I'd suggest "will both be".

Section 4.2.1

  With the Path Vector extension, a site can reveal the bottlenecks
  inside its own network with necessary information (such as link
  capacities) to the ALTO client, instead of providing the full
  topology and routing information.  [...]

I'd suggest adding "or no bottleneck information at all".

Section 4.2.2

  in various documents (e.g., [SEREDGE] and [MOWIE]).  Internet Service
  Providers may deploy multiple layers of CDN caches, or more generally
  service edges, with different latency and available resources
  including number of CPU cores, memory in Gigabytes (G), and storage
  measured in Terabytes (T).

The units are probably not relevant for the abstract scenario, and would
only become relevant when we start introducing Figure 6 as a specific
instantiation of the multi-layer model.

Section 5.1.3

  Specifically, the available properties for a given resource are
  announced in the Information Resource Directory as a new capability
  called "ane-property-names".  The selected properties are specified
  in a filter called "ane-property-names" in the request body, and the
  response includes and only includes the selected properties for the
  ANEs in the response.

Going from the first to second sentence, we switch from using the string
"ane-property-names" to refer to the available properties announced in the
IRD, to using it to refer to the properties that a client supplies in a
path vector query for use in filtering the response results.  To help the
reader make this transition smoothly, I suggest rephrasing the transition,
perhaps to something like "The properties selected by a client as being of
interest are specified in the subsequent Path Vector queries using the
filter called 'ane-property-names'."

Section 5.3

  1.  Since ANEs may be constructed on demand, and potentially based on
      the requested properties (See Section 5.1 for more details).  If

Incomplete sentence.

Section 6.2.4

  multipart response.  Meanwhile, for persistent ANEs whose entity
  domain name has the format of "PROPMAP.ane" where PROPMAP is the name
  of a Property Map resource, PROPMAP is the defining resource of these

Is it better to say "name" of "ResourceID"?

[Ballot discuss]
(Updated ballot to make the remaining issues clear)

Thanks for the update in -20 and in particular all of the new language in the Security considerations to discuss applicability and obfuscation procedures. 

In these edits in response to the earlier DISCUSS text, the following sentence was introduced into Section 11:

For settings where the ALTO server and client are not             
in the same trust domain, Digital Right Management (DRM) techniques         
and legal contracts protecting the sensitive Path Vector information       
MUST be applied.

It appears to be trying to provide guidance on how to ensure that only the expected ALTO clients get the sensitive path information in the case where the server and clients are in different trust domains.  This new language contains normative guidance to using DRM techniques.  Given this is a normative “MUST”, the specifics of “DRM techniques” is under-specified.  Independent of that, DRM techniques I quickly think of provides object security (i.e., embedding a security envelope of some form directly in the data it is trying to protect).  How would that mesh with the specified format for the path information in this document?

[Ballot comment]
Thanks to Samuel Weiler for the SECDIR review.

Thanks for addressing my COMMENTs.

Previous DISCUSS point below
======
Thanks for documenting the increased risk of exposing sensitive topology information and the potentially of this data being exploited for a highly targeted DoS attack in Section 11.  While this significant problem is documented, the mitigation for this fundamental issue is underspecified.  The security of this extension is predicated on the ANE obfuscation procedures, but those specifics are not provided.

In my review, there doesn’t appear to be wide operational usage or implementations of this extension to inform these obfuscation procedures.  Furthermore, it appears that these procedures remain an open research question.  I appreciate the helpful references to the academic papers in Section 11 ([NOVA], [RESA][ MERCATOR])  but their practical applicability to the generic capability provided by this extension appears to be difficulty to align and be caveated.  For example, [RESA] and [MERCATOR] made what appear to be significant assumptions on their approaches, “In this paper, we assume a semi-honest security model, i.e., the aggregator and all member networks will not deviate from the security protocol, but merely try to gather information during the execution of the protocol”. 

I believe this document needs to be provide a stronger applicability statement constraining where it can be fielded and what assumptions are made about the trust models.  Additionally, given the uncertainty on the generic feasibility of obfuscation, this document should be published as experimental.

[Ballot comment]
Section 6.2.1 should be at least a sentence, perhaps:

  The Entity Domain Type is "ane".

I think Section 7.2.1 would be better expressed as:

  The media type of the multipart Filtered Cost Map resource is
  "multipart/related" and the required "type" parameter MUST have
  a value of "application/alto-costmap+json".

By constraining the type to be a specific string, you're removing the flexibility of a MIME parser to allow intervening whitespace, line wrapping, etc.

Why are the RECOMMENDEDs in 7.2.6 and 7.3.6 not REQUIRED?  Is there ever a reason to send them out-of-order?

[Ballot comment]
I am struggling with the fact that even if obfuscated path vector provides more information about network and that the network operators need to be extra careful about providing those information. And draft is actually saying that the ISPs will not share details information. Hence, I am confused about the usability of this protocol but don't want to stand in front of it for being published.

[Ballot comment]
Thank you for the work on this document.

Many thanks to Paul Kyzivat for his review: https://mailarchive.ietf.org/arch/msg/art/S97ViLB3YGpv2ljI9xnQGLCQYgM/ , and thanks to the authors for addressing it.

I only had time to scan the document, but did not find any major ART issues. One thing I noted is that the reference to RFC7540 should be replaced with a ref to draft-ietf-httpbis-http2bis/.

Francesca

[Ballot comment]
[S1; question]

* I assume that all of this querying is inherently asymmetric?

  By that I mean that if an app wants to truly estimate bidirectional flow
  usage between "a" and "b" it needs to query for "a->b" and "b->a", in case
  there's some fundamental asymmetry in flow characteristics.

[S4.2.1; nit]

* s/QEB/QEP/g

[Ballot comment]
I'm balloting No Objection based largely on the basis of the OpsDir review. I have never seen deployments of this, but the OpsDir reviewer is familiar and it appears that the authors have addresses his concerns...

[Ballot discuss]
Thanks for documenting the increased risk of exposing sensitive topology information and the potentially of this data being exploited for a highly targeted DoS attack in Section 11.  While this significant problem is documented, the mitigation for this fundamental issue is underspecified.  The security of this extension is predicated on the ANE obfuscation procedures, but those specifics are not provided.

In my review, there doesn’t appear to be wide operational usage or implementations of this extension to inform these obfuscation procedures.  Furthermore, it appears that these procedures remain an open research question.  I appreciate the helpful references to the academic papers in Section 11 ([NOVA], [RESA][ MERCATOR])  but their practical applicability to the generic capability provided by this extension appears to be difficulty to align and be caveated.  For example, [RESA] and [MERCATOR] made what appear to be significant assumptions on their approaches, “In this paper, we assume a semi-honest security model, i.e., the aggregator and all member networks will not deviate from the security protocol, but merely try to gather information during the execution of the protocol”. 

I believe this document needs to be provide a stronger applicability statement constraining where it can be fielded and what assumptions are made about the trust models.  Additionally, given the uncertainty on the generic feasibility of obfuscation, this document should be published as experimental.

[Ballot comment]
Thanks to Samuel Weiler for the SECDIR review.

** Overstatement of security properties.

Section 1.  For better confidentiality, this document aims to minimize    information exposure. 

Section 5.1.2.  By design, ANEs are ephemeral and not to be used in further requests to other ALTO resources.  More precisely, the corresponding ANE names are no longer valid beyond the scope of the Path Vector response or the incremental update stream for a Path Vector request.  This has several benefits including better privacy of the ISPs and more flexible ANE computation.

The text in both of these sections reads to strongly.  This document defines the ANEs which in fact provides more detailed network information but provides no normative operational guidance or protocol-based protections to minimize (obfuscate) this information.  These claims seem to rest of practices which are out of scope of this document

** Section 5.1.2.  Editorial
  This has
  several benefits including better privacy of the ISPs and more
  flexible ANE computation.

Words are missing from this sentence – “better privacy of the ISPs” what?

** Section 5.1.3.
  Resource-constrained ALTO clients may benefit from the filtering of
  Path Vector query results at the ALTO server ...

Can you describe the use case of these “resource-constrained ALTO clients” as nothing about the use cases in Section 4.2 suggested that the clients were constrained.

** Section 5.2. 
To be pedantic on what’s strictly in C++:

OLD
For
example, in programming languages such as C++, a Path Vector will
have the type of JSONArray.

NEW
For example, in programming languages such as C++ where there existed a JSON array type named JSONArray, a Path Vector will have the type of JSONArray.

[Ballot comment]
Thank you for the work put into this document.


Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Vijay Gurbani for the shepherd's write-up as it seems to indicate a low number of WGLC reviews.

I hope that this helps to improve the document,

Regards,

-éric

While it seems clear that knowledge of the path to some endpoints can help the applications to select the "most suitable" endpoints to connect to, I wonder whether knowledge about a single ISP will be enough. Assuming that a single ISP is the topic of this I-D as the singular form "ISP" is used rather than "ISPs".

Nothing bad of course, but I read this IETF draft more like an IRTF draft, i.e., it reads more like research and conjectures.

As only "max-reservable-bandwidth" is actually specified to this document, I wonder whether other characteristics/properties could also have been defined, e.g., max-latency, max-packet-drop, ... ?

-- Section 3 --
May I assume that the first paragraph should be removed before publication? If so, then please add a note to the RFC Editor.

-- Section 4.2.1 --
On figure 5, please use consistently "v" or "V" but not a mix. Unsure whether "f1" label (?) should be in the picture as it brings nothing.

-- Section 4.2.2 --
I find amusing to see the old telephony concept of "central office(CO)" being used in an IETF draft ;-)

== NITS ==

-- Section 1 --
Please expand IRD at first use.

-- Section 8.1 (and other places) --
Please use only lowercase in IPv6 addresses (and thank you for finally using some IPv6 examples)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-alto-path-vector-15. If any part of this review is inaccurate, please let us know.

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: I-D.ietf-alto-unified-props-new.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in a registry to be created upon the approval of I-D.ietf-alto-unified-props-new

the ALTO Entity Domain Type Registry

a new registration is to be made as follows:

Identifier: ane
Entity Identifier Encoding: [ RFC-to-be; Section 6.2.2 ]
Hierarchy and Inheritance: none
Media type of defining information resource: application/alto-propmap+json
Reference: [ RFC-to-be ]

Second, in a registry to be created upon the approval of I-D.ietf-alto-unified-props-new

ALTO Entity Property Type Registry

two new registrations are to be made as follows:

Identifier: max-reservable-bandwidth
Intended semantics: [ RFC-to-be; Section 6.4.1 ]
Media type of defining information resource:
Reference: [ RFC-to-be ]

Identifier: persistent-entity-id
Intended semantics: [ RFC-to-be; Section 6.4.2 ]
Media type of defining information resource:
Reference: [ RFC-to-be ]

IANA Question --> what are the media types of defining information resource for these two registrations?

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-08-25):

From: The IESG
To: IETF-Announce
CC: alto-chairs@ietf.org, alto@ietf.org, draft-ietf-alto-path-vector@ietf.org, martin.h.duke@gmail.com, vijay.gurbani@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (ALTO Extension: Path Vector) to Proposed Standard


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document: - 'ALTO Extension:
Path Vector'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-08-25. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document is an extension to the base Application-Layer Traffic
  Optimization (ALTO) protocol.  It extends the ALTO Cost Map service
  and ALTO Property Map service so that the application can decide
  which endpoint(s) to connect based on not only numerical/ordinal cost
  values but also details of the paths.  This is useful for
  applications whose performance is impacted by specified components of
  a network on the end-to-end paths, e.g., they may infer that several
  paths share common links and prevent traffic bottlenecks by avoiding
  such paths.  This extension introduces a new abstraction called
  Abstract Network Element (ANE) to represent these components and
  encodes a network path as a vector of ANEs.  Thus, it provides a more
  complete but still abstract graph representation of the underlying
  network(s) for informed traffic optimization among endpoints.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/



No IPR declarations have been submitted directly on this I-D.

1. Summary.

The document shepherd is Vijay K. Gurbani, and the responsible area director is
Martin Duke.

The document is a Standards Track document, targeted as a Proposed Standard.
The WG has chosen the requested publication type since this draft extends the
base ALTO protocol in a normative manner.  Specifically, the document seeks to
extend the base ALTO protocol (RFC 7285) to provide the concept of "Abstract
Network Elements" (ANE).  ANEs are an abstraction of physical network components
--- routers, etc. --- that handle (switch) packets.  An application whose
performance may be impacted by a particular traversal path in the network may
wish to consult the ANEs to determine an optimized path to the destination.

This draft is a major conceptual advance in the abstractions provided by the
base ALTO protocol.

2. Review and consensus.
This work is mature.  It started off as an individual submission in March 2015,
and was adopted as a WG deliverable in May 2017.  A detailed review of this
draft was provided early on by Sabine Randriamasy [1,2,3] shortly after it was
adopted.  Version -04 was further reviewed by Danny Perez [4] and Qiao Xiang [5]
in 2018, and the work progressed appreciably between 2018 and 2019, resulting in
the release of -09 in November 2019.

A WGLC was initiated on Sep-28-2020, and a review was provided by Qiao Xiang [6]
and Luis Contreras [7] on version -11.  Version -12 included the comments from
Qiao and Luis, with version -13 following with some minor revisions.

Earlier versions of path-vector have been implemented (without the integration
of unified-props); the implementation was used in a super computing conference
demonstration for OpenFlow-based networks [8].  The latest version of
path-vector is being implemented and will be open-sourced on GitHub [9].

3. Intellectual property
All of the authors have confirmed with the shephered that they are not aware of
any IPR filed with respect to the draft.

4. Other points
IDNits reports:
  Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--).
Please fix as part of AUTH48.

[1] https://mailarchive.ietf.org/arch/msg/alto/IQ0WwgWewFKJkvzZSIQRhkiN-hc/
[2] https://mailarchive.ietf.org/arch/msg/alto/4wa_kXE4GUrigZ33TBCVVuwBuiw/
[3] https://mailarchive.ietf.org/arch/msg/alto/GGroJgfL5XGuH1ydWOLmISCPMKY/
[4] https://mailarchive.ietf.org/arch/msg/alto/HSGkZ2o4JvneiiYiVSGcCZjDVSQ/
[5] https://mailarchive.ietf.org/arch/msg/alto/qnIBXzFEiYxMDm9kvHLH53qbn_Y/
[6] https://mailarchive.ietf.org/arch/msg/alto/uwFNjekGcc3zMdSKleHU7eIdsW4/
[7] https://mailarchive.ietf.org/arch/msg/alto/D5jkRGws2c75paw6yP8_5_40ViY/
[8] https://github.com/openalto/mercator-setup
[9] https://github.com/openalto/sextant

1. Summary.

The document shepherd is Vijay K. Gurbani, and the responsible area director is
Martin Duke.

The document is a Standards Track document, targeted as a Proposed Standard.
The WG has chosen the requested publication type since this draft extends the
base ALTO protocol in a normative manner.  Specifically, the document seeks to
extend the base ALTO protocol (RFC 7285) to provide the concept of "Abstract
Network Elements" (ANE).  ANEs are an abstraction of physical network components
--- routers, etc. --- that handle (switch) packets.  An application whose
performance may be impacted by a particular traversal path in the network may
wish to consult the ANEs to determine an optimized path to the destination.

This draft is a major conceptual advance in the abstractions provided by the
base ALTO protocol.

2. Review and consensus.
This work is mature.  It started off as an individual submission in March 2015,
and was adopted as a WG deliverable in May 2017.  A detailed review of this
draft was provided early on by Sabine Randriamasy [1,2,3] shortly after it was
adopted.  Version -04 was further reviewed by Danny Perez [4] and Qiao Xiang [5]
in 2018, and the work progressed appreciably between 2018 and 2019, resulting in
the release of -09 in November 2019.

A WGLC was initiated on Sep-28-2020, and a review was provided by Qiao Xiang [6]
and Luis Contreras [7] on version -11.  Version -12 included the comments from
Qiao and Luis, with version -13 following with some minor revisions.

Earlier versions of path-vector have been implemented (without the integration
of unified-props); the implementation was used in a super computing conference
demonstration for OpenFlow-based networks [8].  The latest version of
path-vector is being implemented and will be open-sourced on GitHub [9].

3. Intellectual property
All of the authors have confirmed with the shephered that they are not aware of
any IPR filed with respect to the draft.

4. Other points
IDNits reports:
  Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--).
Please fix as part of AUTH48.

[1] https://mailarchive.ietf.org/arch/msg/alto/IQ0WwgWewFKJkvzZSIQRhkiN-hc/
[2] https://mailarchive.ietf.org/arch/msg/alto/4wa_kXE4GUrigZ33TBCVVuwBuiw/
[3] https://mailarchive.ietf.org/arch/msg/alto/GGroJgfL5XGuH1ydWOLmISCPMKY/
[4] https://mailarchive.ietf.org/arch/msg/alto/HSGkZ2o4JvneiiYiVSGcCZjDVSQ/
[5] https://mailarchive.ietf.org/arch/msg/alto/qnIBXzFEiYxMDm9kvHLH53qbn_Y/
[6] https://mailarchive.ietf.org/arch/msg/alto/uwFNjekGcc3zMdSKleHU7eIdsW4/
[7] https://mailarchive.ietf.org/arch/msg/alto/D5jkRGws2c75paw6yP8_5_40ViY/
[8] https://github.com/openalto/mercator-setup
[9] https://github.com/openalto/sextant

1. Summary.

The document shepherd is Vijay K. Gurbani, and the responsible area director is
Martin Duke.

The document is a Standards Track document, targeted as a Proposed Standard.
The WG has chosen the requested publication type since this draft extends the
base ALTO protocol in a normative manner.  Specifically, the document seeks to
extend the base ALTO protocol (RFC 7285) to provide the concept of "Abstract
Network Elements" (ANE).  ANEs are an abstraction of physical network components
--- routers, etc. --- that handle (switch) packets.  An application whose
performance may be impacted by a particular traversal path in the network may
wish to consult the ANEs to determine an optimized path to the destination.

This draft is a major conceptual advance in the abstractions provided by the
base ALTO protocol.

2. Review and consensus.
This work is mature.  It started off as an individual submission in March 2015,
and was adopted as a WG deliverable in May 2017.  A detailed review of this
draft was provided early on by Sabine Randriamasy [1,2,3] shortly after it was
adopted.  Version -04 was further reviewed by Danny Perez [4] and Qiao Xiang [5]
in 2018, and the work progressed appreciably between 2018 and 2019, resulting in
the release of -09 in November 2019.

A WGLC was initiated on Sep-28-2020, and a review was provided by Qiao Xiang [6]
and Luis Contreras [7] on version -11.  Version -12 included the comments from
Qiao and Luis, with version -13 following with some minor revisions.

Earlier versions of path-vector have been implemented (without the integration
of unified-props); the implementation was used in a super computing conference
demonstration for OpenFlow-based networks [8].  The latest version of
path-vector is being implemented and will be open-sourced on GitHub [9].

The shepherd has an action item to review version -13.

3. Intellectual property
All of the authors have confirmed with the shephered that they are not aware of
any IPR filed with respect to the draft.

4. Other points
IDNits reports:
  Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--).
Please fix as part of AUTH48.

[1] https://mailarchive.ietf.org/arch/msg/alto/IQ0WwgWewFKJkvzZSIQRhkiN-hc/
[2] https://mailarchive.ietf.org/arch/msg/alto/4wa_kXE4GUrigZ33TBCVVuwBuiw/
[3] https://mailarchive.ietf.org/arch/msg/alto/GGroJgfL5XGuH1ydWOLmISCPMKY/
[4] https://mailarchive.ietf.org/arch/msg/alto/HSGkZ2o4JvneiiYiVSGcCZjDVSQ/
[5] https://mailarchive.ietf.org/arch/msg/alto/qnIBXzFEiYxMDm9kvHLH53qbn_Y/
[6] https://mailarchive.ietf.org/arch/msg/alto/uwFNjekGcc3zMdSKleHU7eIdsW4/
[7] https://mailarchive.ietf.org/arch/msg/alto/D5jkRGws2c75paw6yP8_5_40ViY/
[8] https://github.com/openalto/mercator-setup
[9] https://github.com/openalto/sextant

Request for posting confirmation emailed to previous authors: Greg Bernstein , Michael Scharf , Yang Yang , Kai Gao , Wendy Roome , Shiwei Chen , Young Lee , alto-chairs@ietf.org, "J. Zhang"

Request for posting confirmation emailed to previous authors: Greg Bernstein , Michael Scharf , Yang Yang , Wendy Roome , Shiwei Chen , Young Lee , Kai Gao , "J. Zhang"

Request for posting confirmation emailed to previous authors: Greg Bernstein , Michael Scharf , Yang Yang , Kai Gao , "J. Zhang" , Young Lee , Shiwei Chen , alto-chairs@ietf.org, Wendy Roome

Request for posting confirmation emailed to previous authors: Greg Bernstein , Michael Scharf , Yang Yang , "J. Zhang" , Young Lee , Shiwei Chen , Kai Gao , Wendy Roome

Request for posting confirmation emailed to previous authors: Greg Bernstein , Michael Scharf , Yang Yang , "J. Zhang" , Young Lee , Shiwei Chen , Kai Gao , Wendy Roome

Request for posting confirmation emailed to previous authors: Greg Bernstein , Michael Scharf , Yang Yang , Wendy Roome , Shiwei Chen , Young Lee , Kai Gao , "J. Zhang"