Dear Peng, Thank you so much for the feedback. Please see below.
On Fri, Feb 26, 2021 at 9:23 PM 刘鹏 <liupeng...@chinamobile.com> wrote: > Hi WG, > > > Here are some considerations of recharter: > > I believe that the multi domain problem is worthy of attention. > It is good info. > At present, operators also research in it, which may involve guaranteeing > end-to-end network service in the future, such as delay, bandwidth, etc. > There are some researches on cross domain deterministic network in the > industry, which need some support from management and control plane. > Do you want to share some pointers? Who is the provider of Alto service is related to the deployment and > cooperation mode. It may be difficult for operators to give too much > detailed network information now. If the Alto service belongs to the > operator, it may be used to help manage its own network. If Alto service > belong to non operators, I think the issue of how to cooperate needs > further discussion. > > > It looks that you want to consider both modes: multidomains but single operator (i.e., intra-cooperation) and multidomains and multiple operators. Regardless, I agree that it is important for the work to clarify on the privacy requirements. Richard > Regards, > > Peng > > Peng Liu | 刘鹏 > China Mobile | 移动研究院 > mobile phone:13810146105 > email: * liupeng...@chinamobile.com <liupeng...@chinamobile.com>* > > > 发件人: Qin Wu <bill...@huawei.com> > 时间: 2021/02/22(星期一)21:45 > 收件人: IETF ALTO <alto@ietf.org>; > 抄送人: alto-chairs <alto-cha...@ietf.org>;alto-ads <alto-...@ietf.org>; > 主题: [alto] ALTO Draft ReCharter WG review > > 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 > -- -- ===================================== | Y. Richard Yang <y...@cs.yale.edu> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto