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

From: Qin Wu <[email-masked]>
Date: Sun, 17 Oct 2021 04:11:13 +0000

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?

 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?
   Also consider how to integrate generic measurement framework into this data model,
   one relevant work is draft-xie-alto-lmap-00?

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 collect the routing
   data, topology data, performance related data, how these data are translated into network
   map or cost map? I know we support reactive update and proactive update, but it looks
   both are poll based which is slow.

 4. For Access Control, I feel it is confusing, I don't think access control is about a list of
   permissions associated with a system resource (object),e.g, data flow with the specific 5 tuples,
   I think access control is related to security policy such as HTTP authentication,
   TLS client and server authentication, TLS encryption parameters, this can be used not only
   in client server communication but also in server to server communication. I am wondering
   how this can be modelled in the ALTO data model?

-Qin (as individual)

---

From: Qin Wu <[email-masked]>
Date: Wed, 27 Oct 2021 03:54:39 +0000

Hi, Jensen:

发件人: Jensen Zhang [mailto:[email-masked]]
发送时间: 2021年10月26日 9:54
收件人: Qin Wu <[email-masked]>
抄送: [email-masked]; alto-chairs <[email-masked]>; Dhruv Dhody <[email-masked]>
主题: 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<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-%20%20oam-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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi, All:

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.

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.

We also realized the limitations of the current proposed model. And yes, you are right. For the data source aspect, we should support more widely used southbound. So, the URI-based configuration may not be enough.
[Qin Wu] This issue has been brought up last night meeting, I think we use internal and external to distinguish different data source type are confusing, we need to support integrating various different data sources, e.g, whether we can configure ALTO server to support BGP to collect BGP data from BGP data source, or configure ALTO server to support IGP to collect IGP data.
In the current document when you say internal, I think you are referred to use NETCONF YANG to retrieve data. When you say external, I think you mean to use HTTP to retrieve the data.
About how these data are translated into ALTO information resources, it is not the job of the data source part. We propose to use different algorithms to handle this.
[Qin]: Good point, can we provide some references for these algorithms. Integrate different data source with different schema, translation algorithm seems important.

Yes, the access control is related to security policy. But not just server-level authentication. As Sec 16.2.4 of RFC 7285 suggests:

      Security policies mapping potential clients to the information
      that they have privilege to access.

Therefore, it should be at the information resource level. But you are right, the current data model is too simple. More authentication approaches should be added.
[Qin Wu] Good, I see Roland has provided some suggestions for security part.
Thanks,
Jensen

-Qin (as individual)