Re: [alto] ALTO Draft ReCharter WG review -- ALTO Data Model

[Dhruv Dhody <[e-mail]>]

Hi Jensen,

<snip>


>> 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.
>>
>
> My personal feeling is that the configuration requirements for the ALTO
> server and client are very different. e.g., The ALTO server needs to be
> configured which services it can provide, while the ALTO client needs to be
> configured which servers and services it would like to request. So I'm not
> sure if we should define a single YANG model for both client and server.
> But I notice that PCEP defines a single model for both PCE and PCC. From
> your experience, which decision is better for ALTO?
>
>

Dhruv: To me, this would be dependent on what we do with ALTO server-to-server
communication. If one server is acting as a client and would need
management in the same way as a stand-alone ALTO client, then a single
model helps avoid duplication.

<snip>


>> Using the YANG model for monitoring purposes (status, error,
>> statistics) at the ALTO client/server is quite useful.
>>
>
> Thanks for your suggestion. From your experience, which kind of
> information should not be monitored using the YANG model? For example, if
> the client wants to record all the historical requests, should we use the
> YANG model to do it? Or we should only use the YANG model to track the
> immediate status?
>
>
Dhruv: I doubt the ALTO client remembers the past request. YANG cant model
data that doesn't exist. Correct me if I am mistaken. The immediate status,
the statistics, the last error, is what you would usually find!

Thanks!
Dhruv

Thanks,
> Jensen
>
>
>>
>> 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 <[e-mail]> 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
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/alto
>> >
>> > _______________________________________________
>> > alto mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/alto
>>
>