Re: [alto] New Version Notification for draft-ietf-alto-path-vector-14.txt
Dear all, This is the latest revision of the path vector document. In this revision, we have addressed all the comments in the chair review [1-4] and fixed most of the issues raised by IDNits [5] (note that the TBD issue is fixed as mentioned in [4]). There are a few warnings reported by IDNits on the use of example IPv4 addresses, which will be fixed once the submission tool is made available again. Best, Kai [1] https://mailarchive.ietf.org/arch/msg/alto/0V-LL8dk5LRvO2zQ0F6hUYwYi-g/ (responses to chair review 1/2) [2] https://mailarchive.ietf.org/arch/msg/alto/23HfNwNPoYwZqKfwWw6UaAqOLVI/ (follow-up on chair review 1/2) [3] https://mailarchive.ietf.org/arch/msg/alto/Chw-HZl9nt4tsMTyYvFJ_IcQtX8/ (responses to chair review 2/2) [4] https://mailarchive.ietf.org/arch/msg/alto/8jhyV8Hvm-kyYJTLZ5Y3UA8-OaU/ (follow-up on chair review 2/2) [5] https://mailarchive.ietf.org/arch/msg/alto/bUb0sLGjwlXfxiGSc1g_3En9QVA/ -Original Messages- From: internet-dra...@ietf.org Sent Time: 2021-02-23 07:57:59 (Tuesday) To: "J. Zhang" , "Y. Yang" , "Jingxuan Jensen Zhang" , "Kai Gao" , "Sabine Randriamasy" , "Yang Richard Yang" , "Young Lee" Cc: Subject: New Version Notification for draft-ietf-alto-path-vector-14.txt A new version of I-D, draft-ietf-alto-path-vector-14.txt has been successfully submitted by Kai Gao and posted to the IETF repository. Name: draft-ietf-alto-path-vector Revision: 14 Title: ALTO Extension: Path Vector Document date: 2021-02-22 Group: alto Pages: 51 URL: https://www.ietf.org/archive/id/draft-ietf-alto-path-vector-14.txt Status: https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/ Html: https://www.ietf.org/archive/id/draft-ietf-alto-path-vector-14.html Htmlized: https://tools.ietf.org/html/draft-ietf-alto-path-vector-14 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-path-vector-14 Abstract: This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO Cost Map service and ALTO Property Map service so that the application can decide which endpoint(s) to connect based on not only numerical/ordinal cost values but also details of the paths. This is useful for applications whose performance is impacted by specified components of a network on the end-to-end paths, e.g., they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths. This extension introduces a new abstraction called Abstract Network Element (ANE) to represent these components and encodes a network path as a vector of ANEs. Thus, it provides a more complete but still abstract graph representation of the underlying network(s) for informed traffic optimization among endpoints. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt
Dear all, This version 16 addresses most of Vijay's review comments part 1 and 2. We will come back in a few days with details on how the comments have been addressed. Thanks, Sabine >-Original Message- >From: alto On Behalf Of internet-dra...@ietf.org >Sent: Tuesday, February 23, 2021 1:01 AM >To: i-d-annou...@ietf.org >Cc: alto@ietf.org >Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Application-Layer Traffic Optimization WG of >the >IETF. > >Title : ALTO extension: Entity Property Maps >Authors : Wendy Roome > Sabine Randriamasy > Y. Richard Yang > Jingxuan Jensen Zhang > Kai Gao > Filename: draft-ietf-alto-unified-props-new-16.txt > Pages : 57 > Date: 2021-02-22 > >Abstract: > This document extends the base Application-Layer Traffic Optimization > (ALTO) Protocol by generalizing the concept of "endpoint properties" > as applied to endpoints as defined by IP addresses to endpoints > defined by a wider set of objects. Further, these properties are > presented as maps, similar to the network and cost maps in the base > ALTO protocol. The protocol is extended in two major directions. > First, from endpoints restricted to IP addresses to entities covering > a wider and extensible set of objects; second, from properties on > specific endpoints to entire entity property maps. These extensions > introduce additional features allowing entities and property values > to be specific to a given information resource. This is made > possible by a generic and flexible design of entity and property > types. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ > >There are also htmlized versions available at: >https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-16 >https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-16 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-16 > > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > > >___ >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] I-D Action: draft-ietf-alto-unified-props-new-16.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application-Layer Traffic Optimization WG of the IETF. Title : ALTO extension: Entity Property Maps Authors : Wendy Roome Sabine Randriamasy Y. Richard Yang Jingxuan Jensen Zhang Kai Gao Filename: draft-ietf-alto-unified-props-new-16.txt Pages : 57 Date: 2021-02-22 Abstract: This document extends the base Application-Layer Traffic Optimization (ALTO) Protocol by generalizing the concept of "endpoint properties" as applied to endpoints as defined by IP addresses to endpoints defined by a wider set of objects. Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO protocol. The protocol is extended in two major directions. First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties on specific endpoints to entire entity property maps. These extensions introduce additional features allowing entities and property values to be specific to a given information resource. This is made possible by a generic and flexible design of entity and property types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-16 https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] I-D Action: draft-ietf-alto-path-vector-14.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application-Layer Traffic Optimization WG of the IETF. Title : ALTO Extension: Path Vector Authors : Kai Gao Young Lee Sabine Randriamasy Yang Richard Yang Jingxuan Jensen Zhang Filename: draft-ietf-alto-path-vector-14.txt Pages : 51 Date: 2021-02-22 Abstract: This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO Cost Map service and ALTO Property Map service so that the application can decide which endpoint(s) to connect based on not only numerical/ordinal cost values but also details of the paths. This is useful for applications whose performance is impacted by specified components of a network on the end-to-end paths, e.g., they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths. This extension introduces a new abstraction called Abstract Network Element (ANE) to represent these components and encodes a network path as a vector of ANEs. Thus, it provides a more complete but still abstract graph representation of the underlying network(s) for informed traffic optimization among endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-alto-path-vector-14.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-path-vector-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Chair review of path-vector-13 (Part 1 of 2)
Hi Vijay and the ALTO WG, This is a follow-up on the comments that are not fully address in the previous email. Please see below. Thanks! Best, Kai -Original Messages- From:"Vijay Gurbani" Sent Time:2021-02-08 23:35:13 (Monday) To: draft-ietf-alto-path-vec...@ietf.org Cc: "IETF ALTO" Subject: Chair review of path-vector-13 (Part 1 of 2) Chair review from beginning of document to the end of S6.6. Part 1 of 2. Major: - S4.1, below Figure 2: Note that we do not have "availbw" defined in ALTO as a current cost metric, so it is not a good idea to use it here without qualifying it further. If used as is, it creates confusion. My advice would be to either qualify the use of "availbw" as a hypothetical cost metric, or choose an actual cost metric from the performance-metric draft and restate the example. - S4.1, "Case 1": I don't see how the "application will obtain 150 Mbps at most." Consider that the bottleneck bandwidth is 100 Mbps, as that is the bandwidth of the most constrained link. Once traffic leaves sw5, it can get no more than 100 Mbps on the remaining links. So, I don't understand how the "application will obtain 150 Mbps at most."? Perhaps I am missing something? - S4.2.3: This paragraph, especially the second sentence onwards needs to be re-written to better flesh out the need. Currently it says, "While both approaches...", however, it is not clear that there are two approaches being delineated from each other here. It needs more edits so it reads better. (Some nits in this paragraph appear in the Nits section trying to tease out the language.) - S5.1.3: When Section 5 begins, it says that "This section gives a non-normative overview of the Path Vector extension." However, in S5.1.3, there is a normative "MUST". (Same problem in S5.3, there are many "MUST"s there, and in Section 5.3.3 there are "RECOMMENDED" and "SHOULD NOT".) Generally, I am a bit hesitant that certain subsections of Section 5 --- Section 5.3.2 in particular --- appear to contain normative behaviour, and this should be specified in a normative section, or do NOT start Section 5 by saying that this section gives a non-normative overview, and make this a normative section. I understand this is a major comment, so please think how you want to handle this carefully. - S5.3.2: Not sure I follow the logic in the first paragraph. As Fig. 4 showed, there is one PV request, and if ALTO SSE extension is being used, presumably, it will contain the "client-id". If the response contains a Path Vector resource, shouldn't that "client-id" simply apply to it? I am sure I am missing something here as you have thought about this more than me; perhaps you could add a simple example to make the problem more explicit. - S6.4: Why have a mini Security Considerations paragraphs in the subsections of S6.4, but not in the subsections of S6.3 and S6.5? I am not saying that you remove the mini Security Considerations paragraphs, but if there are security considerations worth pointing out in S6.4, I suspect that there are security considerations worth pointing out in S6.3 and S6.5? (One such security consideration is listed below in S6.5.1.) - S6.4.2: "The persistent entity ID property is the entity identifier of the persistent ANE which an ephemeral ANE presents (See Section 5.1.2 for details)." ==> I am not sure what this means? Why is an ephemeral ANE presenting a persistent entity identifier? Is it important that you are defining an ephemeral ANE and associating it with persistent entities? If so, then please make this clear as there is a lot of ambiguity in this section. - S6.5.1: What is the effect if the ALTO server chooses to obfuscate the path vector, causing the client to experience sub-optimal routing. The client does not know that the server has obfuscated the path vector, so it MUST interpret the path vector as given to it by the ALTO server. This raises the question whether such obfuscation, because it is indistinguishable from a non-obfuscated response, creates an attack on the client? (Would a mini Security Consideration paragraph be appropriate here?) Clearly, since ALTO assumes that the server is trusted to some degree, the issue becomes (a) can the client, by repeated querying, figure out that it is being duped on occasion? (b) what does it then do? [PV] The effects are highly implementation-specific, and it is true that obfuscation may create an attack on the client by compromising the integrity of ALTO information. As we discuss in Section 11, there are some obfuscation methods that can preserve the integrity of the information. Regarding the last two issues, the answer to (a) is also implementation- and network-specific, if the obfuscation is idempotent, i.e., generating the same obfuscated results for the same request, a client will not be able to figure out that it is being duped; even if a client sees two
[alto] [ALTO] Meeting Info for Feb 23, 2021
Dear all, This is a friendly reminder that we will have the ALTO weekly meeting at 9:00 am US EST (3:00 pm CET and 10:00 pm Beijing Time) on Tuesday, Feb 23, 2021. Agenda: - The progress of WG documents, in particular UP and PV (5 - 10 min) - Recharter discussion - Overall planning (10 min) - Multidomain (10 min) - Operation automation & Data model in automation (10 min) - General extension (10 min) - New operational considerations (10 min) If anyone wants to discuss another topic, please let me know. Bridge: https://yale.zoom.us/my/yryang By the way, the deadline of submitting Internet drafts is 2021-02-22 23:59 UTC. Best, Kai___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[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
