Re: [alto] Meeting Info for Oct 26, 2021

[Qin Wu]

Thank Jensen to provide ALTO OAM work status update in the weekly meeting. Two 
open issues are brought up:

1.   How to understand the intent based interface?

2.   When we say internal or external, compare with who, it is internal or 
external?
A few quick suggestions to your shared slides:

1.   We all agree RFC7285 and RFC7971 are a good basis for ALTO OAM work, 
especially section 16 of RFC7285, you also list a bunches of protocol extension 
RFCs,

I suggest we can make a table to list which requirements are from which RFCs, 
in order to support some of these protocol extensions which parameters we need 
to define to configure ALTO server?

2.   Regarding the goal, we need to better understand which is in the 
scope, which is not in the scope?

3.   Provide the definitions in the terminology section for intent based 
interface if we want to keep using it.

4.   Find a better wording for internal and external and allow integration 
with other data sources.


-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 kai...@scu.edu.cn
发送时间: 2021年10月25日 22:43
收件人: alto@ietf.org; alto-weekly-meet...@googlegroups.com
主题: [alto] Meeting Info for Oct 26, 2021


Dear all,



This is a friendly reminder that we will have the weekly ALTO meeting at 9:00 
am US EST (3:00 pm CET and 9:00 pm Beijing Time) on Tuesday, October 26, 2021.



Agenda:

- Planning for IETF 112



The ALTO session will be hosted on November 10, 16:00-18:00 UTC.



Bridge:

https://yale.zoom.us/my/yryang



If anyone wants to discuss another topic, please feel free to let me know.



Best,

Kai
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] 转发: Kick off discussion on ALTO OAM work

[Qin Wu]

Good questions, Jensen, would you like to clarify these issues?

-Qin
发件人: roland.sch...@telekom.de [mailto:roland.sch...@telekom.de]
发送时间: 2021年10月26日 21:28
收件人: jen...@jensen-zhang.site; Qin Wu 
抄送: dhruv.i...@gmail.com
主题: AW: Kick off discussion on ALTO OAM work

Hi all,

thank you Qin for introducing me.

I have just looked at the document, but need to have a deeper look into it.

My first questions are:

1)
rw auth
 |   |  +--rw (auth-type-selection)
 |   | +--:(auth-key-chain)
 |   | +--:(auth-key)
 |   | +--:(auth-tls)



Are all kind of tls protocol versions possible or do we have limitations?


2)
To use the reactive update, the reactive attribute MUST be set true. To use the 
proactive update, the poll-interval attribute MUST be greater than zero.
The value of poll-interval specifies the interval of fetching the data in 
milliseconds.

The poll interval is accurate. Is this set because of observation of bursts or 
are longer intervals also an option reducing the poll overhead?
Any configuration option available?

Best Regards

Roland



Von: Jensen Zhang mailto:jen...@jensen-zhang.site>>
Gesendet: Dienstag, 26. Oktober 2021 03:57
An: Qin Wu mailto:bill...@huawei.com>>
Cc: Schott, Roland mailto:roland.sch...@telekom.de>>; 
Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Betreff: Re: Kick off discussion on ALTO OAM work

Hi Roland,

The latest version of the draft can be found at GitHub right now: 
https://openalto.github.io/draft-alto-oam-yang/draft-zhang-alto-oam-yang.html

We missed the early submission deadline of the datatracker. But we will upload 
it to the datatracker once the submission page is reopened.

For more details, we are going to discuss them in the coming ALTO weekly 
meeting. I see Qin had forwarded the meeting info. Welcome to join and give any 
feedback.

Thanks,
Jensen

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

Re: [alto] Kick off discussion on ALTO OAM work

[Qin Wu]

Hi, Jensen:

发件人: Jensen Zhang [mailto:jen...@jensen-zhang.site]
发送时间: 2021年10月26日 9:54
收件人: Qin Wu 
抄送: alto@ietf.org; alto-chairs ; Dhruv Dhody 

主题: Re: Kick off discussion on ALTO OAM work

Hi Qin and all,

The updated version of the ALTO OAM draft is available here: 
https://openalto.github.io/draft-alto-oam-yang/draft-zhang-alto-oam-yang.html

[Qin Wu] Thank for the update, I believe many of us want to see the diff,
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-zhang-alto-oam-yang.txt&url2=https://openalto.github.io/draft-alto-oam-yang/draft-zhang-alto-
  
oam-yang.txt

We missed the early submission deadline of the datatracker. But we will upload 
the document once the submission page is reopened. Before the IETF 112, we 
still want to share this updated work and get some early feedback from WG.

We will also have some early discussions in the coming ALTO weekly meeting. If 
you are interested in this work, please feel free to join.

Also, thanks for the comments from Qin. Please see my feedback inline.

On Sun, Oct 17, 2021 at 12:11 PM Qin Wu 
mailto:bill...@huawei.com>> wrote:
Hi, All:
I want to kick off discussion on ALTO OAM work. One relevant draft is
https://datatracker.ietf.org/doc/html/draft-zhang-alto-oam-yang-00.txt
Thank authors for this proposed work. I have gone through this draft and
have several comments and suggestions:

1.   I agree management consideration provide a set of requirements for ALTO
   data model design and is a good input to this document. I am wondering
   whether we have other reference work as input such as server discovery,
  server to server communication, I assume ALTO deployment document can be
   one of them, related to sever to server communication, what about server
   discovery? Do we need to configure the ALTO client for server discovery?
   Do we need to configure ALTO server for server discovery, suppose we use
   DNS mechanism to discover ALTO server, I think we actually need to configure
   DNS server? What am I missing? I encourage to take a close look at server
   discovery aspect, what is needed for ALTO data model?

I totally agree with you.
Although the current version does not define any data model for ALTO server 
discovery, it is in the plan.

[Qin Wu] We need to decide what is in the scope, what is not in the scope? For 
ALTO server discovery, I am thinking this is more related to ALTO client 
configuration,
At current stage, we didn’t cover ALTO client configuration. ALTO client may 
use DHCP mechanism to discover the ALTO server or DNS mechanism for ALTO server 
discovery or
Neighbor discovery, I am not sure anycast can leveraged, this needs to be 
investigated, I think.

 2. I agree we need to better manage ALTO information resource and data source,
   Do we need to monitor ALTO information resource lifecycle management, what is
   missing part is performance measurement aspect, I think we should reference
   section 16.2.5 to see how to provide ALTO information resource monitoring?

That is a good point. The new version also has an initial proposal for 
statistics suggested by Sec 16.2.5 of RFC7285. But we add the statistics very 
carefully.

Also, I think we should make one principle clear: if a feature can have already 
been provided by an existing OAM tool, we shouldn't define it in the ALTO OAM 
data model repeatedly. In other words, this document should only focus on 
ALTO-specific features.
[Qin]:Sure, we MUST reuse existing OAM tools, avoid inventing new wheels, the 
focus of this draft, in my thinking is how to leverage existing OAM tools
to measure ALTO service performance. Therefore defining some performance 
evaluation method or performance index, metrics are the key that can be covered 
by this models.
   Also consider how to integrate generic measurement framework into this data 
model,
   one relevant work is draft-xie-alto-lmap-00?

This work is quite interesting. But for my understanding, it leverages the ALTO 
base protocol, not the OAM data model. So I guess it is more related to your 
third item?

[Qin Wu] I think this is related to data source and data collection mechanism 
modeling, we can see performance data as another type of data source. you may 
also need to collect performance data using some OAM tools, LMAP provides 
generic measurement framework for High speed internet service or broadband 
network service. ALTO OAM model may need to consider how to generalize their 
measurement framework and integrate with ALTO.
The relevant work in LMAP WG is RFC8193, RFC8194.

3.For data source aspect, I am wondering whether we should also consider not 
only where
   to collect data, but also how to collect data or what kind of data we can 
collect?
   e.g., we can use pub sub mechanism to collect the data, suppose we coll

Re: [alto] Opsdir last call review of draft-ietf-alto-path-vector-17

[kaigao]

Dear Time,

We have just submitted a revision of the Path Vector draft (-19). Below
are the links to the latest revision and the diffs. Please see inline
the pointers to the proposed changes to the comments, in brief:

1. More detailed examples are given in Sec 4.2:
   a. what is the role of ALTO server/client in the scenario;
   b. what an ANE represents and what information can be provided;
   c. how the ALTO client can use the information.
2. Clarification texts for "domain" in Sec 6.2.
3. Clarification texts is added in Sec 6.4.1 for the role of ALTO
   when the property "max-reservable-bandwidth" is provided.
4. Examples of the initial properties are explained in Sec 6.4.3.

Draft:
https://www.ietf.org/archive/id/draft-ietf-alto-path-vector-19.html

Diffs:
https://www.ietf.org/rfcdiff?url1=draft-ietf-alto-path-vector-17&url2=draft-ietf-alto-path-vector-19

With the revision, we hope the draft is now clearer and easier to follow.
Please feel free to let us know if there are further comments or suggestions.
Thanks!

Best,
Kai


> -Original Messages-
> From: "Tim Chown" 
> Sent Time: 2021-09-27 17:40:10 (Monday)
> To: "kai...@scu.edu.cn" 
> Cc: "ops-...@ietf.org" , "alto@ietf.org" 
, "draft-ietf-alto-path-vector@ietf.org" 
, "last-c...@ietf.org" 

> Subject: Re: Opsdir last call review of draft-ietf-alto-path-vector-17
> 
> Hi,
> 
> > On 24 Sep 2021, at 07:54, kai...@scu.edu.cn wrote:
> > 
> > Hi Tim,
> > 
> > Thanks for the review and suggestion. We agree that more concrete use 
cases and 
> > examples will be helpful and some parts of the document need to be 
better 
> > clarified. We will revise the document accordingly. Please see inline 
for detailed 
> > comments.
> 
> Inline with TC> …
> 
> > Best,
> > Kai
> > 
> > > -Original Messages-
> > > From: "Tim Chown via Datatracker" 
> > > Sent Time: 2021-09-09 19:49:56 (Thursday)
> > > To: ops-...@ietf.org
> > > Cc: alto@ietf.org, draft-ietf-alto-path-vector@ietf.org, 
last-c...@ietf.org
> > > Subject: Opsdir last call review of 
draft-ietf-alto-path-vector-17
> > > 
> > > Reviewer: Tim Chown
> > > Review result: Not Ready
> > > 
> > > Hi,
> > > 
> > > I have reviewed this document (draft-ietf-opsec-v6-26) as part 
of the
> > > Operational directorate's ongoing effort to review all IETF 
documents being
> > > processed by the IESG.  These comments were written with the 
intent of
> > > improving the operational aspects of the IETF drafts. Comments 
that are not
> > > addressed in last call may be included in AD reviews during the 
IESG review. 
> > > Document editors and WG chairs should treat these comments just 
like any other
> > > last call comments.
> > > 
> > > This draft proposes an extension to the ALTO protocol to allow 
the definition
> > > of Abstract Network Elements (ANEs) on a path between two 
endpoints that can be
> > > considered when orchestrating connectivity between those 
endpoints, rather than
> > > just computing based on the abstract cost of a path.  A Path 
Vector allows a
> > > set of such ANEs to be defined for a path.
> > > 
> > > Caveat:
> > > 
> > > I am generally familiar with the work of the ALTO group.  My 
work at Jisc, a
> > > national research and education network, includes assisting 
universities and
> > > research organisations optimise large scale data transfers (up 
to petabytes of
> > > data).
> > > 
> > > Overall:
> > > 
> > > I believe the document is generally well written, and the 
problem space it is
> > > addressing is one for which there is value in defining a 
solution, but I feel
> > > the document suffers from being too abstract and vague about 
what it is
> > > defining, and its consideration of practical use cases could be 
improved.  Thus
> > > I feel at this stage it is Not Ready for publication.
> > > 
> > > General comments:
> > > 
> > > The use cases defined are quite varied - large scale analytics, 
mobile and
> > > CDNs.  SENSE and LHC are not specifically data analytics use 
cases in the usual
> > > sense of the word, rather SENSE is a model for orchestrating 
network links (and
> > > capacity) between sites, and the LHC provides large scale data 
sets for four
> > > major experiments that are distributed and computed upon via the 
WLCG
> > > (worldwide large hadron collider computing grid).
> > 
> > KAI:
> > The document was first originated to support the data analytics use 
case, but
> > later was found to be useful in other scenarios. We will focus on the
> > analytics use case in the next revision.
> 
> TC>  OK, that’s fine.  I know from speaking to people in groups such as 
at the GNA-G
> Data Intensive Science WG that alto principles are of interest, but it 
would take some
> significant effort to adopt them.   So perhaps there’s a future 
Informational document
> To be written around that use case.
> 

KAI: Indeed. Some early studies that investigate the direction of using ALTO to 
provide
resource discovery in data science networks (UNICORN and ReSA) are inclu

Re: [alto] Genart last call review of draft-ietf-alto-path-vector-17

[kaigao]

Dear Suresh,

Please see below our latest revision of the Path Vector draft (-19). We have
added IPv6 examples for each endpoint-based example. We hope this addresses
your comments.

Draft:
https://www.ietf.org/archive/id/draft-ietf-alto-path-vector-19.html

Diffs:
https://www.ietf.org/rfcdiff?url1=draft-ietf-alto-path-vector-17&url2=draft-ietf-alto-path-vector-19

Thanks!

Best,
Kai


> -Original Messages-
> From: kai...@scu.edu.cn
> Sent Time: 2021-08-31 00:26:49 (Tuesday)
> To: "Suresh Krishnan" 
> Cc: draft-ietf-alto-path-vector@ietf.org, last-c...@ietf.org, 
gen-...@ietf.org, alto@ietf.org
> Subject: Re: [alto] Genart last call review of 
draft-ietf-alto-path-vector-17
> 
> Hi Suresh,
> 
> Thanks for the comment. We will add IPv6 examples in Section 8 in the next 
revision as soon as possible.
> 
> Best,
> Kai
> 
> "Suresh Krishnan via Datatracker" wrote:
> > Reviewer: Suresh Krishnan
> > Review result: Ready with Nits
> > 
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed
> > by the IESG for the IETF Chair.  Please treat these comments just
> > like any other last call comments.
> > 
> > For more information, please see the FAQ at
> > 
> > .
> > 
> > Document: draft-ietf-alto-path-vector-??
> > Reviewer: Suresh Krishnan
> > Review Date: 2021-08-30
> > IETF LC End Date: 2021-08-25
> > IESG Telechat date: Not scheduled for a telechat
> > 
> > Summary:
> > 
> > Overall, the document is well done and easy to read for someone with a
> > background in past work done at alto.
> > 
> > Major issues:
> > 
> > Minor issues:
> > 
> > Nits/editorial comments:
> > 
> > Please add some IPv6 examples in Section 8.
> > 
> > 
> > ___
> > alto mailing list
> > alto@ietf.org
> > https://www.ietf.org/mailman/listinfo/alto
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto

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

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

[kaigao]

Dear WG members and reviewers,

We have just submitted a new version of the Path Vector draft. This revision
addresses the comments in the Last Call reviews, most notably:

1. Add IPv6 examples
2. Change the "content-id" format in multipart messages to conform to RFC 2387 
& 5322
3. Add descriptions of potential use cases including
   a. what is the role of ALTO server/client
   b. what information can be provided
   c. how the ALTO client may use the information
4. Add examples for abstract network elements in Sec 5.1
5. Add a paragraph to clarify "ANE domain" in Sec 6.2
6. Add paragraphs to emphasize the role of ALTO when providing 
max-reservable-bandwidth property

Diffs:
https://www.ietf.org/rfcdiff?url1=draft-ietf-alto-path-vector-17&url2=draft-ietf-alto-path-vector-19

Best,
Kai


-Original Messages-
From: internet-dra...@ietf.org
Sent Time: 2021-10-26 07:34:54 (Tuesday)
To: i-d-annou...@ietf.org
Cc: alto@ietf.org
Subject: [alto] I-D Action: draft-ietf-alto-path-vector-19.txt


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
Authors : Kai Gao
  Young Lee
  Sabine Randriamasy
  Yang Richard Yang
  Jingxuan Jensen Zhang
Filename: draft-ietf-alto-path-vector-19.txt
Pages   : 63
Date: 2021-10-25

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-alto-path-vector-19.html

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


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


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

Re: [alto] Designated Experts

[kaigao]

Hi Martin,

Sorry for the late response. I had a discussion with Qin yesterday on the 
responsibility of designated experts. I think I can do it.

Best,
Kai

2021-10-27 03:18:35"Martin Duke" wrote:

Kai, does this work for you?


Any other nominations?


On Mon, Oct 25, 2021 at 10:57 PM Qin Wu  wrote:


Hi, Martin:

I suggest Kai, as the primary, I can be the backup.

 

-Qin

发件人: alto [mailto:alto-boun...@ietf.org] 代表 Martin Duke
发送时间: 2021年10月26日 8:43
收件人: IETF ALTO 
主题: [alto] Designated Experts

 

Who will be the designated experts for the ALTO Cost Source Registry in 
ietf-alto-performance-metrics?

 

Once I have a couple of volunteers, this can go to IESG evaluation.___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Designated Experts

[Qin Wu]

Thanks Martin, Kai agreed to do this in last night weekly meeting discussion.
Yes, this is IETF review. Thank for checking registration procedure type.

-Qin
发件人: Martin Duke [mailto:martin.h.d...@gmail.com]
发送时间: 2021年10月27日 6:03
收件人: Qin Wu 
抄送: IETF ALTO 
主题: Re: [alto] Designated Experts

Never mind, this is IETF review, so there is no DE needed.

On Tue, Oct 26, 2021 at 12:18 PM Martin Duke 
mailto:martin.h.d...@gmail.com>> wrote:
Kai, does this work for you?

Any other nominations?

On Mon, Oct 25, 2021 at 10:57 PM Qin Wu 
mailto:bill...@huawei.com>> wrote:
Hi, Martin:
I suggest Kai, as the primary, I can be the backup.

-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 
Martin Duke
发送时间: 2021年10月26日 8:43
收件人: IETF ALTO mailto:alto@ietf.org>>
主题: [alto] Designated Experts

Who will be the designated experts for the ALTO Cost Source Registry in 
ietf-alto-performance-metrics?

Once I have a couple of volunteers, this can go to IESG evaluation.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Designated Experts

[Martin Duke]

Never mind, this is IETF review, so there is no DE needed.

On Tue, Oct 26, 2021 at 12:18 PM Martin Duke 
wrote:

> Kai, does this work for you?
>
> Any other nominations?
>
> On Mon, Oct 25, 2021 at 10:57 PM Qin Wu  wrote:
>
>> Hi, Martin:
>>
>> I suggest Kai, as the primary, I can be the backup.
>>
>>
>>
>> -Qin
>>
>> *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Martin Duke
>> *发送时间:* 2021年10月26日 8:43
>> *收件人:* IETF ALTO 
>> *主题:* [alto] Designated Experts
>>
>>
>>
>> Who will be the designated experts for the ALTO Cost Source Registry in
>> ietf-alto-performance-metrics?
>>
>>
>>
>> Once I have a couple of volunteers, this can go to IESG evaluation.
>>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Designated Experts

[Martin Duke]

Kai, does this work for you?

Any other nominations?

On Mon, Oct 25, 2021 at 10:57 PM Qin Wu  wrote:

> Hi, Martin:
>
> I suggest Kai, as the primary, I can be the backup.
>
>
>
> -Qin
>
> *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Martin Duke
> *发送时间:* 2021年10月26日 8:43
> *收件人:* IETF ALTO 
> *主题:* [alto] Designated Experts
>
>
>
> Who will be the designated experts for the ALTO Cost Source Registry in
> ietf-alto-performance-metrics?
>
>
>
> Once I have a couple of volunteers, this can go to IESG evaluation.
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Meeting Info for Oct 26, 2021

[Jensen Zhang]

Hi all,

Thanks for the great discussion today. The slides for today's ALTO OAM
discussion are available here:
https://docs.google.com/presentation/d/1ZptSLG8NBdN0zM20MPcjLLvlqI81GtdSLU70-o-XYys/edit?usp=sharing

I haven't got a chance to present all the open discussion items. They are
listed on the last page. Welcome to discuss and give further comments.

Thanks,
Jensen


On Mon, Oct 25, 2021 at 10:44 PM  wrote:

> Dear all,
>
>
> This is a friendly reminder that we will have the weekly ALTO meeting at
> 9:00 am US EST (3:00 pm CET and 9:00 pm Beijing Time) on Tuesday, October
> 26, 2021.
>
>
> *Agenda:*
>
> - Planning for IETF 112
>
>
> The ALTO session will be hosted on November 10, 16:00-18:00 UTC.
>
>
> *Bridge:*
>
> https://yale.zoom.us/my/yryang
>
>
> If anyone wants to discuss another topic, please feel free to let me know.
>
>
> Best,
>
> Kai
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto