[alto] ALTO pipeline discussions

[Qiao Xiang]

Dear WG members,

As posted in Richard's earlier email, we want to discuss items that are not
working group documents but are of interests to the WG. This email is to
share my preliminary thoughts on two items: (1) How should ALTO information
be integrated/utilize in orchestration; and (2) Use mathematical
programming representation abstraction as unified resource representation.

The motivation for me to look into these items are (1) How to represent
resource sharing of flows with on-demand routing? and (2) How to represent
shared risk link group (SRLG) information of flows? Both these motivating
questions are raised during our earlier discussion with people from LNBL
and ESNet, one of the major use cases of ALTO. They are highly interested
in the linear inequality abstraction introduced in the ALTO path vector
draft.

My first design proposal is to use "generalized disjunctive programming"
(GDP) as the abstraction. GDP is an optimization modeling technique that
can encode not only linear/integer constraints, but logical propositions. I
believe it is a good candidate for unified resource representation in ALTO
because it is highly expressive and easy to interpret. I prepare a few
simple slides to illustrate the basic idea of my design, and will write
down the specs in a draft before the cut-off date. Meanwhile, it will be
greatly appreciated if you could share your comments or thoughts on this
design,

Thank you very much.


Best
Qiao

Dear all,
It is 24 days to the scheduled ALTO session, on July 16. After this
weekend, it will be only 3 weeks. During the last couple of months, to
better prepare for the coming IETF, some of us (Danny, Dawn, Lyle, Jensen,
Sabine, Shawn, Qiao, Christian) looked at both the current state and the
pipeline of ALTO.
For the current-state part, Dawn/Danny/Shawn are doing a wonderful review
of ALTO, on ALTO implementations, ALTO in related work. They will continue
to lead the efforts.
The objective of this email is to start a thread to discuss the pipeline
aspect. We want to discuss items that are not working group documents but
have interests. We may or may not have a chance to work on these items, but
will definitely help to get the discussion started.
At a high, rough level, we can classify ALTO pipeline into three
categories, and in each category, we can identify several potential working
items. At the end of this email is a list. We are hoping that we can have a
good discussion on this before and during the coming IETF.
Cheers,
Richard, on behalf of Danny, Dawn, Lyle, Jensen, Sabine, Shawn, Qiao,
Christian
* - App use cases/requirements/architecture 1. A systematic study of how
ALTO info be integrated/utilize in orchestration 1. One aspect ALTO + PCE,
ABNO, Path-based, 2. Extension to new architectures (e.g., cellular, 5G)
endpoint types 3. Extension to new settings such as multi-domain (ALTO is
traditional design for App-Net, i.e., north-south interface, interdomain is
more EW interface), SFC, NFV, edge clouds - API/base protocol 1. A general
multipart service, SSE -> HTTP/2 2. Flow cost service, extensible query
schema for a set of flows, may including unicast and multicast, multipath,
... 3. Calendar for endpoint entity properties [Sabine] 4. Unified resource
representation (e.g., mathematical programming representation abstraction,
linear inq) - Backend/infrastructure 1. Smart/on-demand measurements (query
miss trigger, start and collect measurements, formalize the protocol,
connect to IPPM, accuracy/freshness, what kind of info to be provided) 2.
Proxy architecture, for scale, interdomain, for fault tolerance, for
security/privacy -- Qiao Xiang Postdoctoral Fellow, Department of Computer
Science,Yale University*

[Bertz, Lyle T [CTO]]

All,

I am unsure if where to place this in the list but the ability to introduce new metrics into the system is a must. I know it sounds easy enough in ALTO but consider what should be done when an ALTO server does not currently support a metric, i.e. heterogeneous metrics between servers. Would a mechanism be possible to

a. Acquire the ability to provide a new metric

b. Announce (as opposed to wait for a Client to connect) the new capability

Complementing this with on demand measurements should provide a fairly complete solution.

We have found that in orchestration many networks and vendors are adding new metrics (VNF descriptors) prior to code supporting or code being upgrade to support these metrics. It would be ideal to get ahead of this situation and offer a solution that can measure prior to needing the measurements for orchestration.

From: Qiao Xiang [mailto:***@gmail.com]
Sent: Wednesday, June 27, 2018 1:21 AM
To: IETF ALTO <***@ietf.org>
Cc: Randriamasy, Sabine (Nokia - FR/Nozay) <***@nokia-bell-labs.com>; Bertz, Lyle T [CTO] <***@sprint.com>; Danny Alex Lachos Perez <***@gmail.com>; Chan Dawn <***@hotmail.com>; Jensen Zhang <***@jensen-zhang.site>; Xiao Lin <***@gmail.com>; Christian Esteve Rothenberg <***@dca.fee.unicamp.br>; Y. Richard Yang <***@cs.yale.edu>
Subject: Re: ALTO pipeline discussions

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Dear WG members,

As posted in Richard's earlier email, we want to discuss items that are not working group documents but are of interests to the WG. This email is to share my preliminary thoughts on two items: (1) How should ALTO information be integrated/utilize in orchestration; and (2) Use mathematical programming representation abstraction as unified resource representation.

The motivation for me to look into these items are (1) How to represent resource sharing of flows with on-demand routing? and (2) How to represent shared risk link group (SRLG) information of flows? Both these motivating questions are raised during our earlier discussion with people from LNBL and ESNet, one of the major use cases of ALTO. They are highly interested in the linear inequality abstraction introduced in the ALTO path vector draft.

My first design proposal is to use "generalized disjunctive programming" (GDP) as the abstraction. GDP is an optimization modeling technique that can encode not only linear/integer constraints, but logical propositions. I believe it is a good candidate for unified resource representation in ALTO because it is highly expressive and easy to interpret. I prepare a few simple slides to illustrate the basic idea of my design, and will write down the specs in a draft before the cut-off date. Meanwhile, it will be greatly appreciated if you could share your comments or thoughts on this design,

Thank you very much.


Best
Qiao

On Thu, Jun 21, 2018 at 9:58 PM Y. Richard Yang <***@cs.yale.edu<mailto:***@cs.yale.edu>> wrote:
Dear all,

It is 24 days to the scheduled ALTO session, on July 16. After this weekend, it will be only 3 weeks. During the last couple of months, to better prepare for the coming IETF, some of us (Danny, Dawn, Lyle, Jensen, Sabine, Shawn, Qiao, Christian) looked at both the current state and the pipeline of ALTO.

For the current-state part, Dawn/Danny/Shawn are doing a wonderful review of ALTO, on ALTO implementations, ALTO in related work. They will continue to lead the efforts.

The objective of this email is to start a thread to discuss the pipeline aspect. We want to discuss items that are not working group documents but have interests. We may or may not have a chance to work on these items, but will definitely help to get the discussion started.

At a high, rough level, we can classify ALTO pipeline into three categories, and in each category, we can identify several potential working items. At the end of this email is a list. We are hoping that we can have a good discussion on this before and during the coming IETF.

Cheers,
Richard, on behalf of Danny, Dawn, Lyle, Jensen, Sabine, Shawn, Qiao, Christian



- App use cases/requirements/architecture

1. A systematic study of how ALTO info be integrated/utilize in orchestration

a. One aspect ALTO + PCE, ABNO, Path-based,

2. Extension to new architectures (e.g., cellular, 5G) endpoint types

3. Extension to new settings such as multi-domain (ALTO is traditional design for App-Net, i.e., north-south interface, interdomain is more EW interface), SFC, NFV, edge clouds

- API/base protocol

1. A general multipart service, SSE -> HTTP/2

2. Flow cost service, extensible query schema for a set of flows, may including unicast and multicast, multipath, ...

3. Calendar for endpoint entity properties [Sabine]

4. Unified resource representation (e.g., mathematical programming representation abstraction, linear inq)

- Backend/infrastructure

1. Smart/on-demand measurements (query miss trigger, start and collect measurements, formalize the protocol, connect to IPPM, accuracy/freshness, what kind of info to be provided)

2. Proxy architecture, for scale, interdomain, for fault tolerance, for security/privacy

[Bertz, Lyle T [CTO]]

Per your comments


For (a), do you mean the ALTO client can acquire some new metric, or the operator of ALTO server can add a new metric dynamically? I feel the later is more convinced. Maybe it depends on the implementation, but we can define the formal API and mechanism to support it.

Definitely the latter here. In NFV when a new VNF descriptor is introduced (standard or otherwise) there can be incredible pain to support it within the Orchestration and underlying system. Unfortunately it currently requires code updates to all components when in reality, be it a property or metric, it can be generically handled with the exception of the underlying code that supports its computation.

For (b), doesn't the incremental update of IRD handle it? I feel the [draft-ietf-incr-update-sse] can already handle it if the ALTO client subscribes the incremental update notification of IRD. Which additional features do we need?

Ah yes! I am old and forgetful this week and thinking of some code and not the specs. Thank you!

From: Jensen Zhang [mailto:***@jensen-zhang.site]
Sent: Wednesday, June 27, 2018 8:04 AM
To: Bertz, Lyle T [CTO] <***@sprint.com>
Cc: Qiao Xiang <***@gmail.com>; IETF ALTO <***@ietf.org>; Randriamasy, Sabine (Nokia - FR/Nozay) <***@nokia-bell-labs.com>; Danny Alex Lachos Perez <***@gmail.com>; Chan Dawn <***@hotmail.com>; Xiao Lin <***@gmail.com>; Christian Esteve Rothenberg <***@dca.fee.unicamp.br>; Y. Richard Yang <***@cs.yale.edu>
Subject: Re: ALTO pipeline discussions

Hi Qiao and Lyle,

Thanks for your sharing ideas. I would like to join the discussion. :)

Qiao,

Using GDP to represent network resources sounds interesting. But I believe only providing some kind of representation is not enough to support the use cases like LNBL and ESNet. We actually need to solve three problems:

1. How to request the resources
2. How to represent the resources
3. How to response the resources

I believe the unified resource representation, the draft which you are working on, is going to focus on item 2. I'm not sure whether we also want to solve item 3 in this draft. But I believe the newer use cases are requiring the evolution of item 1, the new request schema and mechanism. (Maybe the survey Dawn, Shawn, and Danny are working on can provide some information to support me) And it is still seldom discussed in WG.

Although the FCS draft I'm working on is about this part, it may not be enough. The unified resource representation may involve multiple ALTO resources (endpoint cost + property map, or multiple property maps). So Dawn and I are working on a new extension to support querying multiple resources in a single session. We introduce some general query languages to provide the relational query. The current write up already can be accessed [1]. We will finish a complete version in this week to submit.

Lyle,

You point is very interesting. I'm trying to understand the real issues.

For (a), do you mean the ALTO client can acquire some new metric, or the operator of ALTO server can add a new metric dynamically? I feel the later is more convinced. Maybe it depends on the implementation, but we can define the formal API and mechanism to support it.

For (b), doesn't the incremental update of IRD handle it? I feel the [draft-ietf-incr-update-sse] can already handle it if the ALTO client subscribes the incremental update notification of IRD. Which additional features do we need?

[1] https://openalto.github.io/alto-multipart/draft-tbd-alto-multipart.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenalto.github.io%2Falto-multipart%2Fdraft-tbd-alto-multipart.html&data=02%7C01%7CLyle.T.Bertz%40sprint.com%7C240a70a6c68042b7fb1008d5dc2e834b%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636657014696881819&sdata=1mviQ%2Bd8Pt4s4Wi0XEAdN3ZfqV1J5TXjRvEoXAE0Aoc%3D&reserved=0>

Best,
Jensen

On Wed, Jun 27, 2018 at 7:52 PM Bertz, Lyle T [CTO] <***@sprint.com<mailto:***@sprint.com>> wrote:
All,

I am unsure if where to place this in the list but the ability to introduce new metrics into the system is a must. I know it sounds easy enough in ALTO but consider what should be done when an ALTO server does not currently support a metric, i.e. heterogeneous metrics between servers. Would a mechanism be possible to

a. Acquire the ability to provide a new metric

b. Announce (as opposed to wait for a Client to connect) the new capability

Complementing this with on demand measurements should provide a fairly complete solution.

We have found that in orchestration many networks and vendors are adding new metrics (VNF descriptors) prior to code supporting or code being upgrade to support these metrics. It would be ideal to get ahead of this situation and offer a solution that can measure prior to needing the measurements for orchestration.

From: Qiao Xiang [mailto:***@gmail.com<mailto:***@gmail.com>]
Sent: Wednesday, June 27, 2018 1:21 AM
To: IETF ALTO <***@ietf.org<mailto:***@ietf.org>>
Cc: Randriamasy, Sabine (Nokia - FR/Nozay) <***@nokia-bell-labs.com<mailto:***@nokia-bell-labs.com>>; Bertz, Lyle T [CTO] <***@sprint.com<mailto:***@sprint.com>>; Danny Alex Lachos Perez <***@gmail.com<mailto:***@gmail.com>>; Chan Dawn <***@hotmail.com<mailto:***@hotmail.com>>; Jensen Zhang <***@jensen-zhang.site<mailto:***@jensen-zhang.site>>; Xiao Lin <***@gmail.com<mailto:***@gmail.com>>; Christian Esteve Rothenberg <***@dca.fee.unicamp.br<mailto:***@dca.fee.unicamp.br>>; Y. Richard Yang <***@cs.yale.edu<mailto:***@cs.yale.edu>>
Subject: Re: ALTO pipeline discussions

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Dear WG members,

As posted in Richard's earlier email, we want to discuss items that are not working group documents but are of interests to the WG. This email is to share my preliminary thoughts on two items: (1) How should ALTO information be integrated/utilize in orchestration; and (2) Use mathematical programming representation abstraction as unified resource representation.

The motivation for me to look into these items are (1) How to represent resource sharing of flows with on-demand routing? and (2) How to represent shared risk link group (SRLG) information of flows? Both these motivating questions are raised during our earlier discussion with people from LNBL and ESNet, one of the major use cases of ALTO. They are highly interested in the linear inequality abstraction introduced in the ALTO path vector draft.

My first design proposal is to use "generalized disjunctive programming" (GDP) as the abstraction. GDP is an optimization modeling technique that can encode not only linear/integer constraints, but logical propositions. I believe it is a good candidate for unified resource representation in ALTO because it is highly expressive and easy to interpret. I prepare a few simple slides to illustrate the basic idea of my design, and will write down the specs in a draft before the cut-off date. Meanwhile, it will be greatly appreciated if you could share your comments or thoughts on this design,

Thank you very much.


Best
Qiao

On Thu, Jun 21, 2018 at 9:58 PM Y. Richard Yang <***@cs.yale.edu<mailto:***@cs.yale.edu>> wrote:
Dear all,

It is 24 days to the scheduled ALTO session, on July 16. After this weekend, it will be only 3 weeks. During the last couple of months, to better prepare for the coming IETF, some of us (Danny, Dawn, Lyle, Jensen, Sabine, Shawn, Qiao, Christian) looked at both the current state and the pipeline of ALTO.

For the current-state part, Dawn/Danny/Shawn are doing a wonderful review of ALTO, on ALTO implementations, ALTO in related work. They will continue to lead the efforts.

The objective of this email is to start a thread to discuss the pipeline aspect. We want to discuss items that are not working group documents but have interests. We may or may not have a chance to work on these items, but will definitely help to get the discussion started.

At a high, rough level, we can classify ALTO pipeline into three categories, and in each category, we can identify several potential working items. At the end of this email is a list. We are hoping that we can have a good discussion on this before and during the coming IETF.

Cheers,
Richard, on behalf of Danny, Dawn, Lyle, Jensen, Sabine, Shawn, Qiao, Christian


- App use cases/requirements/architecture

1. A systematic study of how ALTO info be integrated/utilize in orchestration

a. One aspect ALTO + PCE, ABNO, Path-based,

2. Extension to new architectures (e.g., cellular, 5G) endpoint types

3. Extension to new settings such as multi-domain (ALTO is traditional design for App-Net, i.e., north-south interface, interdomain is more EW interface), SFC, NFV, edge clouds

- API/base protocol

1. A general multipart service, SSE -> HTTP/2

2. Flow cost service, extensible query schema for a set of flows, may including unicast and multicast, multipath, ...

3. Calendar for endpoint entity properties [Sabine]

4. Unified resource representation (e.g., mathematical programming representation abstraction, linear inq)

- Backend/infrastructure

1. Smart/on-demand measurements (query miss trigger, start and collect measurements, formalize the protocol, connect to IPPM, accuracy/freshness, what kind of info to be provided)

2. Proxy architecture, for scale, interdomain, for fault tolerance, for security/privacy