Hi, authors of draft-ietf-alto-oam-yang:
Thank for the update of this important work, as we know ALTO simply provides a
query interface for network information exposure, however,
how ALTO system is bootstrapped, how to capture all the network information
needed such as network topology information, traffic flow information, network
performance information
to build and update network map, cost map, property map, this require operation
automation, ALTO OAM play a key role to address this gap. Therefore, I believe
we need to rethink
the model design from a holistic view. Here are a few quick comments on the
latest version of this draft:
1. We get one complaint from PYANG tool. Can you fix pyang error?
"[email protected]:585: error: RFC 8407: 4.10: top-level node
alto-server must not be mandatory"
2. Section 1 said:
"
The operator can use the data model to create and update ALTO information
resources, manage the access control, configure server-to-server
communication and server discovery, and collect statistical data.
"
I am thinking who will be consumer of this document, the operators such as
network operator, ISP, are one of them, how about regulators, the third party
entity who can also benefit from using this model to benchmark ALTO service
provide by different operators.
for server to server communication, I re-read ALTO deployment RFC7971 said:
"
ALTO is inherently
designed for use in multi-domain environments. Most importantly,
ALTO is designed to enable deployments in which the ALTO server and
the ALTO client are not located within the same administrative
domain.
"
"
o Multiple administrative domains: The ALTO protocol is designed for
use cases where the ALTO server and client can be located in
different organizations or trust domains. ALTO assumes a loose
coupling between server and client. In addition, ALTO does not
assume that an ALTO client has any a priori knowledge about the
ALTO server and its supported features. An ALTO server can be
discovered automatically.
"
I think we should support the case where the ALTO server and client can be
located in
different organizations or trust domains. To support this case, server to
server communication is needed,
otherwise,how do you evaluate the total amount of inter-domain traffic of an
ISP,how do you assess
application performance improvement by the introduction of ALTO.
3. Section 1 said:
"
Although the scope of the YANG data
model in this document mainly focuses on the support of the base ALTO
protocol [RFC7285] and the existing ALTO standard extensions
(including [RFC8189], [RFC8895], [RFC8896], [RFC9240], [RFC9241], and
{RFC9275}), the design will also be extensible for future standard
extensions (e.g., [I-D.ietf-alto-performance-metrics]).
"
When [I-D.ietf-alto-performance-metrics] gets published as RFC, the last
sentence will not hold. I suggest to change
into something else, e.g., JOSE objects carrying ALTO payloads [RFC7165]
4. Section 4.1 said:
Data model for deploy an ALTO server/client.
Do we need to support ALTO client configuration, please consider Placement of
ALTO Entities in section 2.1.2 of RFC7971
do we support ALTO client embeded in app case and ALTO client embeded in
resource diretory cases?
5. Section 4.1 said:
"
This document does not define any data model related to specific
implementation, including:
* Data structures for how to store/deliver ALTO information
resources (e.g., database schema to store a network map).
* Data structures for how to store information collected from data
sources. (e.g., database schema to store topology collected from
an Interface to the Routing System (I2RS) client [RFC7921])
"
I think we need to rethink this part from the holistic view, data structures
for ALTO information storing is not in the scope,
but data structures for ALTO information export or delivering is not in the
scope, I am not sure about this.
See figure 1 of RFC7285, RFC7285 said:
"
Figure 1 illustrates that the ALTO information provided by an ALTO
server may be influenced (at the service provider's discretion) by
other systems. In particular, the ALTO server can aggregate
information from multiple systems to provide an abstract and unified
view that can be more useful to applications. Examples of other
systems include (but are not limited to) static network configuration
databases, dynamic network information, routing protocols,
provisioning policies, and interfaces to outside parties.
"
I think we should support aggregating information from various different data
source or system,
we can get data from routing protocol e.g.,RFC7752 defined in IDR WG, RFC8233
defined in PCE WG,RFC8671, RFC9069 defined in GROW WG,RFC8430 defined in I2RS
WG, etc
we can get flow data from IPFIX protocol RFC7011,
OAM data from OAM protocol, tools, mechanism such as OAM tool set defined in
table 5 of RFC7276,
PM data from IOAM protocol[RFC9197], TWMAP [RFC5357], etc
6. Section 4.2
what is the difference between security policy management and Access control
requirements?
7. Section 6.1
Do you have model snippet for ALTO-specific Performance Monitoring? Or it is
still open for further design?
7.Section 5.2.1.1 ALTO Server Listen Stack
It looks alto-server-grouping aligns with draft-ietf-tcpm-yang-tcp and
draft-ietf-netconf-tls-client-server,draft-ietf-netconf-tcp-client-server-13,
I am wondering why we only support ALTO Server configuration without client
configuration?
draft-ietf-netconf-tls-client-server,draft-ietf-netconf-tcp-client-server-13
did support client configuration.
8.5.2.1.2. ALTO Server Discovery Setup
Why server to server communication is mixed with ALTO Server Discovery? they
are in different phase, no?
-Qin
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
