Subject: [alto] I-D Action: draft-ietf-alto-path-vector-04.txt

From: [email-masked]
Date: Mon, 02 Jul 2018 12:46:03 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of the IETF.

        Title           : ALTO Extension: Path Vector Cost Type
        Authors         : Greg Bernstein
                          Shiwei Dawn Chen
                          Kai Gao
                          Young Lee
                          Wendy Roome
                          Michael Scharf
                          Y. Richard Yang
                          Jingxuan Jensen Zhang
	Filename        : draft-ietf-alto-path-vector-04.txt
	Pages           : 29
	Date            : 2018-07-02

Abstract:
   The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285]
   has defined cost maps and endpoint cost maps to provide basic network
   information.  However, they provide only scalar (numerical or
   ordinal) cost mode values, which are insufficient to satisfy the
   demands of solving more complex network optimization problems.  This
   document introduces an extension to the base ALTO protocol, namely
   the path-vector extension, which allows ALTO clients to query
   information such as capacity regions for a given set of flows.  A
   non-normative example called multi-flow scheduling is presented to
   illustrate the limitations of existing ALTO endpoint cost maps.
   After that, details of the extension are defined.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-path-vector-04
https://datatracker.ietf.org/doc/html/draft-ietf-alto-path-vector-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-path-vector-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jensen Zhang <[email-masked]>
Date: Mon, 2 Jul 2018 16:08:23 -0400

Hi all,

In this revision -04, we do the following changes:

- The major change is to decouple the multipart query service from the path
vector.
    - Instead, A capability called "allow-compound-response" is introduced
to make the property map inline.
    - The multipart query service is moved to a new document and defined
for the general cases.
- The examples section is revised to better explain the usage of the path
vector extension.
- The compatibility of the path vector extension is better clarified.
- Some general discussions are raised.

Looking forward to receiving your feedback.

Thanks,
Jensen

On Tue, Jul 3, 2018 at 3:46 AM <[email-masked]> wrote:

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Danny Alex Lachos Perez <[email-masked]>
Date: Tue, 10 Jul 2018 18:39:28 -0300

Hi Jensen and WG

I started to review the draft. I have one technical comment that I would
like to share:

In section 5.1 (Cost Mode :  Array):
*"This document extends the CostMode defined in Section 10.5 of [RFC7285]
with a new cost mode: "array".  This cost mode indicates that every cost
value in a cost map represents an array rather than a simple value.  The
values are arrays of JSONValue."*

It seems that the current path-vector draft can not support
multi-paths between source/destination points. What if an ALTO client wants
to know the different paths (or all paths) for a pair of endpoints or
PIDs?. For example, in the Broker-assisted architecture, a filtered cost
map could provide an array of arrays of values to provide all possible
paths for each source and destination node.

Let me know your thoughts about that.

Ss

Danny Lachos

On Mon, Jul 2, 2018 at 5:08 PM Jensen Zhang <[email-masked]>
wrote:

> - The major change is to decouple the multipart query service from the
> path vector.
>>    illustrate the limitations of existing ALTO endpoint cost maps..

---

From: Qiao Xiang <[email-masked]>
Date: Tue, 10 Jul 2018 21:38:44 -0400

Dear authors of the PV draft and the ALTO WG members,

I finished reviewing the first few sections (abstract and Section 1-4) of
the latest PV draft. The marked documents are attached in this email (with
mark "[qiao]"). More importantly, I want to raise the discussion on the
following design issues in this draft, to seek your feedback:

1. The design choice of using "array/sequence/list of abstract network
elements (ANEs)".

We all know that the concept "path vector" in this draft was highly
motivated by BGP, a path-vector interdomain routing protocol. In BGP, a
path vector encodes an AS path, which provides the semantics that to reach
a destination IP prefix, which ASes will be traversed in what "order". The
AS-path vector has semantics: (1) the first one in the vector is the
neighbor AS providing this route, (2) the last one is the destination AS
providing the destination IP prefix, (3) The ASes in between help provide
information about inter-AS connectivity. In contrast, a path vector in ALTO
is an ANE-path. What semantics does it have? In order words, why does the
order of ANEs matter? One may argue that it may help provide information
like "a flow will pass through a firewall middlebox before entering a DPI
middlebox", but why would a network operator want to provide such detailed
private information to the application? Is there a strong, reasonable use
case?

It just occurred to me that Danny's multi-domain broker draft tries to use
the PV extension to provide the AS-path information for different NFs. This
may be a strong case to use the array of ANEs, instead of a set of ANEs, in
the PV draft. However, such information is already provided by BGP and will
be the source of an ALTO server getting such information, why is ALTO
better than BGP at providing such information?

I see 3 ways that we can proceed:

(1) we keep the current design, and provide strong use cases in the draft
to justify "array of ANEs" is necessary, and explicitly state that the
application must recognize that the returned array of ANEs MUST be unordered
;
(2) we keep the current design, do not provide strong use cases to justify
this design, but explicitly state that the server MAY return the array of
ANEs unordered;
(3) we change the design from "array of ANEs" to "set of ANEs" (i.e., cost
mode changed from "array" to "set").

2. Handling multipath (and potentially multicast).

The current PV design does not handle multipath routing or multicast.
Richard suggested me take a look at how BGP handles multipath,  given that
PV was highly motivated by BGP. I found RFC7911 ("Advertisement of Multiple
Paths in BGP") provides the solution. And the basic idea is very simple: in
BGP announcement, assigning an ID (path identifier) to the route. This
motivates me to propose the following design to let the PV extension
support multipath.

Consider a source-destination pair (a flow), its route (no matter
single-path route or multipath route) is essentially a set of route
segments. When the ALTO client submits a PV query about this flow to the
ALTO server. Instead of returning an array of ANEs, the ALO server returns
a set of arrays of ANEs, where each array represents a route segment in the
route of this flow and is assigned a unique ID. These IDs are also sent to
the ALTO client. In addition to the property map of all ANEs used in these
route segments, the ALTO server also sends another property map of all
route segments, where the property is "traffic load percentage". For
example, assuming the flow uses 2 paths:

(ANE1 -> ANE2 ->ANE3 ->ANE4) and (ANE1->ANE2->ANE5->ANE4), then the ALTO
server tells the ALTO client that there are 3 route segments:

RS1: [ANE1, ANE2], RS2: [ANE2, ANE3, ANE4], RS3:  [ANE2, ANE5, ANE4];

It also tells the ALTo client 2 property maps. The first one is:

ANE1: { "availbw": 50 },
ANE2: { "availbw": 50 },
ANE3: { "availbw": 50 },
ANE4: { "availbw": 50 },
ANE5: { "availbw": 50 }

The second one is:

RS1: {"trafficloadpercentage": 1},
RS2: {"trafficloadpercentage": 0.6},
RS3: {"trafficloadpercentage": 0.4}.

I believe this design perfectly provides accurate, compact information of
resource sharing in multipath routing. It can also handle the resource
sharing defined by TE policies, and can potentially provide such
information in multicast, provided that the query format supports a query
on multicast flow.

What do you think about these two issues? If they reasonable to most of
you, may I suggest integrating this design into the next version of the PV
draft? Thank you very much.

Best
Qiao

-- 
Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University