Hi Jensen,
Thanks for starting this thread. It is great that you are thinking of
similar questions as I was :)
On Wed, Mar 3, 2021 at 9:03 PM Jensen Zhang <jingxuan.n.zh...@gmail.com> wrote:
>
> Dear all,
>
> I would like to make some comments on the 3rd recharter item.
>
> This item is going to propose YANG data models for ALTO configuration and
> management. Most of this kind of YANG data models for communication protocols
> like PCEP [1] and HTTP [2] will support both client and server configuration.
> One of the open issues for ALTO is:
>
> whether we should also provide the data model for the ALTO client
> configuration.
>
If the ALTO client is a function that can be placed in an entity that
uses YANG-based techniques for configuration, status check, and
monitoring. It makes sense for us to provide support for ALTO-client
in YANG model. Some of the use-cases you are already highlighting
below. For some like P2P tracker not soo much!
> For some of the traditional ALTO use cases like p2p, I think the YANG data
> model only for the ALTO server is enough. It can help the network operator
> easily configure and manage ALTO services. The data model for the ALTO client
> may not be necessary because the client is usually not under the control of
> the network operator. However, there are two cases where people may be
> interested in the data model for the ALTO client:
>
> 1. The multi-domain setting is a potential use case. But it depends on how we
> are going to design the server-to-server communication.
>
> (a) If we are going to reuse the current ALTO framework, then the
> architecture could be similar to the PCE-based architecture, i.e., each ALTO
> domain should initiate an entity that can be an alto-server, alto-client, or
> alto-server-and-client. And for the alto-client or alto-server-and-client
> entity, the operator could configure the list of peered
> alto-server/alto-server-and-client entity directly, or how to discover the
> peers. The operator could also configure which information the client entity
> is interested in and would like to fetch from the peers.
>
> (b) If we are going to completely redesign the communication protocol among
> ALTO servers, we may need specific data models for the configuration of this
> new protocol. The traditional roles of the ALTO client and server may no
> longer be applicable.
>
Yes the YANG needs to follow whatever decision is taken regarding the
ALTO server-to-server communication. There is also a high-level
decision that if we have a single YANG model for ALTO that can be used
by both client and server or have independent yang models: one for
client and another for server.
BTW RFC 7971 includes this -
Cascaded servers: An ALTO server may itself include an ALTO
client and query other ALTO servers, e.g., for certain
destinations. This results is a cascaded deployment of ALTO
servers, as further explained below.
> 2. The other use case could come from the network-application integration.
> More specifically, the multi-service operator (e.g., Comcast, Telefonica) who
> can offer both application service (e.g., TV, CDN) and network service can be
> an example. In such a case, the application service operator may have some
> collaboration with the network operator on the protocol configuration level.
>
> For example, in a CDN-ISP collaboration setting (@Luis can comment on it),
> the CDN operator may request the network operator to install a new ALTO
> service to compute on-demand ALTO information resources based on new
> parameters dynamically. And in the meantime, the CDN operator may also
> configure its own ALTO client to periodically send requests to the new ALTO
> service or use the pub/sub mechanism (e.g. SSE). And the CDN operator may
> want the ALTO client to report some operational status/statistics like when
> the last request is done, whether the last response is out-dated, how many
> versions are updated for the current information resource (Not quite sure if
> this info should be in the scope of the ALTO data model). It makes more sense
> to do these kinds of things via the configuration protocol instead of another
> ALTO protocol extension.
>
Using the YANG model for monitoring purposes (status, error,
statistics) at the ALTO client/server is quite useful.
Thanks,
Dhruv
> It would be great if people can share further comments or their own
> interesting use cases.
>
> [1] https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-15
> [2] https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-06
>
> Best regards,
> Jensen
>
>
> On Mon, Feb 22, 2021 at 9:51 PM Qin Wu <bill...@huawei.com> wrote:
>>
>> Hi, :
>>
>> We have requested one hour session for ALTO WG meeting in the upcoming IETF
>> 110, which is arranged on Friday, March 12, 14:30-15:30(UTC).
>>
>> The goal is to boil down ALTO recharter and have consensus on charter
>> contents in IETF 110.
>>
>> To get this goal, an updated inline draft charter text for ALTO has just
>> been posted to this list,
>>
>> This charter has received a couple of rounds of informal review from WG
>> members, chairs and our Ads from brief to deep thorough, 5 new chartered
>> items have been listed.
>>
>> We would like to solicit feedback on these new chartered items and your use
>> case, deployment, idea corresponding to these new chartered items.
>>
>> Sharing your past deployment story will also be appreciated.
>>
>>
>>
>> ============================================================================================
>>
>> The ALTO working group was established in 2008 to devise a request/response
>> protocol to allow a host to benefit from a server that is more cognizant of
>> the network infrastructure than the host is.
>>
>>
>>
>> The working group has developed an HTTP-based protocol and recent work has
>> reported large-scale deployment of ALTO based solutions supporting
>> applications such as content distribution networks (CDN).
>>
>>
>>
>> ALTO is now proposed as a component for cloud-based interactive
>> applications, large-scale data analytics, multi-cloud SD-WAN deployment, and
>> distributed
>>
>> computing. In all these cases, exposing network information such as abstract
>> topologies and network function deployment location helps applications.
>>
>>
>>
>> To support these emerging uses, extensions are needed, and additional
>> functional and architectural features need to be considered as follows:
>>
>>
>>
>> o Protocol extensions to support a richer and extensible set of policy
>> attributes in ALTO information update request and response. Such policy
>> attributes may indicate information dependency (e.g., ALTO path-cost/QoS
>> properties with dependency on real-time network indications), optimization
>> criteria (e.g., lowest latency/throughput network performance objective),
>> and constraints (e.g., relaxation bound of optimization criteria, domain or
>> network node to be traversed, diversity and redundancy of paths).
>>
>>
>>
>> o Protocol extensions for facilitating operational automation tasks and
>> improving transport efficiency. In particular, extensions to provide
>> "pub/sub" mechanisms to allow the client to request and receive a diverse
>> types (such as event-triggered/sporadic, continuous), continuous, customized
>> feed of publisher-generated information. Efforts developed in other working
>> groups such as MQTT Publish / Subscribe Architecture, WebSub, Subscription
>> to YANG Notifications will be considered, and issues such as scalability
>> (e.g., using unicast or broadcast/multicast, and periodicity of object
>> updates) should be considered.
>>
>>
>>
>> o The working group will investigate the configuration, management, and
>> operation of ALTO systems and may develop suitable data models.
>>
>>
>>
>> o Extensions to ALTO services to support multi-domain settings. ALTO is
>> currently specified for a single ALTO server in a single administrative
>> domain, but a network may consist of
>>
>> multiple domains and the potential information sources may not be limited to
>> a certain domain. The working group will investigate extending the ALTO
>> framework to (1) specify multi-ALTO-server protocol flow and usage
>> guidelines when an ALTO service involves network paths spanning multiple
>> domains with multiple ALTO servers, and (2) extend or introduce ALTO
>>
>> services allowing east-west interfaces for multiple ALTO server integration
>> and collaboration. The specifications and extensions should use existing
>> services whenever possible. The specifications and extensions should
>> consider realistic complexities including incremental deployment,
>> dynamicity, and security issues such as access control, authorization (e.g.,
>> an ALTO server provides information for a network that the server has no
>> authorization), and privacy protection in multi-domain settings.
>>
>>
>>
>> o The working group will update RFC 7971 to provide operational
>> considerations for recent protocol extensions (e.g., cost calendar, unified
>> properties, and path vector) and new extensions that the WG develops. New
>> considerations will include decisions about the set of information resources
>> (e.g., what metrics to use), notification of changes either in proactive or
>> reactive mode (e.g., pull the backend, or trigger just-in-time
>> measurements), aggregation/processing of the collected information (e.g.,
>> compute information and network information )according to the clients’
>> requests, and integration with new transport mechanisms (e.g., HTTP/2 and
>> HTTP/3).
>>
>>
>>
>> When the WG considers standardizing information that the ALTO server could
>> provide, the following criteria are important
>>
>> to ensure real feasibility:
>>
>>
>>
>> - Can the ALTO server realistically provide (measure or derive) that
>> information?
>>
>>
>>
>> - Is it information that the ALTO client cannot find easily some other way?
>>
>>
>>
>> - Is the distribution of the information allowed by the operator of the
>> network? Does the exposure of the information introduce privacy and
>> information leakage concerns?
>>
>>
>>
>> Issues related to the specific content exchanged in systems that make use of
>> ALTO are excluded from the WG's scope, as is the issue of dealing with
>> enforcing the legality of the content. The WG will also not propose
>> standards on how congestion is signaled, remediated, or avoided.
>>
>>
>>
>> -Qin Wu (on behalf of chairs)
>>
>> _______________________________________________
>> 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
