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

[i***@ietf.org]

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/

[Jensen Zhang]

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

Post by i***@ietf.org
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
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.
https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
https://tools.ietf.org/html/draft-ietf-alto-path-vector-04
https://datatracker.ietf.org/doc/html/draft-ietf-alto-path-vector-04
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

[Danny Alex Lachos Perez]

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

Post by Jensen Zhang
Hi all,
- 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

Post by i***@ietf.org
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
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.
https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
https://tools.ietf.org/html/draft-ietf-alto-path-vector-04
https://datatracker.ietf.org/doc/html/draft-ietf-alto-path-vector-04
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

[Qiao Xiang]

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

Post by Jensen Zhang
Hi all,
- 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

Post by i***@ietf.org
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
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.
https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
https://tools.ietf.org/html/draft-ietf-alto-path-vector-04
https://datatracker.ietf.org/doc/html/draft-ietf-alto-path-vector-04
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto