Thank you Qin for your feedback, great points. Below my comments: It is interesting topic, I think it is also related to what PANRG and COINRG are doing.
I agree. I will also be presenting my two drafts on bottleneck structures (single domain and multi-domain) in the PANRG session on Thursday 11/10. 1. First Computation of Bottleneck Substructures is computation intensive, which might require in network computing support. In this draft, the proposed bottleneck structure is based on the path gradient graph (described in this other draft https://datatracker.ietf.org/doc/draft-giraltyellamraju-alto-bsg-requirements/), which achieves much greater scalability without loosing accuracy. We think this approach is not computationally intensive (and have evidence of that from benchmarks carried out in some US-scale production networks.) 2. The multi-domain setting has been documented in ALTO deployment RFC, see quoted text: "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." "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." Great quotes of the current RFCs. The integration of multi-domain bottleneck structures to ALTO is in general a server-to-server communication feature. If server-to-server communication in ALTO is not an option, then the computation of the bottleneck substructures could be carried out outside the ALTO server. This is mentioned in the Requirements Section of the draft: "An alternative architecture could consider executing these events in a separated engine, and have the ALTO server query this engine to obtain the final bottleneck structures, decoupling the distributed protocol from the ALTO standard". 3. When you say the distributed protocol proposed in this document could be used as a use case to help drive the specifications of the inter-server communication protocol discussed in [I-D.draft-zhang-alto-oam-yang], I am not sure we should couple the distributed protocol you proposed with server to server communication. I agree that I don't think we should couple multidomain bottleneck structures with the OAM from a standards point of view. The statement is mostly about the possibility that OAM could refer to this draft as an example of server-to-server communication. There are different types of communication; I think Jensen referred to this as algorithmic inter-domain communication. This statement might confuse things more than necessary; I am happy to drop it from the draft. I think ALTO OAM is positioned to integrate various different tools to capture network data, oam data, flow data, build network map and cost map. Existing protocol can be used, such as routing protocol, OAM protocol, IPFIX, do you want to propose to use ALTO to define such distribute protocol? It's a question that we need to reach consensus on. It could be within ALTO, or outside. As mentioned, I am also presenting this draft in the PANRG WG and a goal is to collect feedback on finding the most suitable WG where this protocol could be integrated. I think ALTO is a natural fit for incorporating bottleneck structures (next to network map, cost map, etc.), but there can be other WGs with similar fit. why BGP is not sufficient? The proposed protocol is similar to BGP in that it's a border protocol, scalable and can converge to global optimality by using only local information. BGP, however, computes routes without taking into account the network's flow dynamics (i.e., the bottleneck structure graph, BSG). We think that the proposed protocol can run in parallel to BGP to help make optimized routing decisions based on the BSG. Also distribute information across domain has a big security concern, how do you address this? We are hoping this is a strength of the proposed protocol, because the bottleneck structure graph can be seen as an object that synthesizes the current state of the network in a compact way, and removing flow sensitive information (getting it down to the minimum necessary information needed to make optimized routing decisions). 4. Let's take a close look at PATH_METRIC_ANNOUNCEMENT, what packet format looks like? what parameters are carried in PATH_METRIC_ANNOUNCEMENT? The path metric of autonomous system A_i for path p, PM(A_i)(p), is a single scalar value. See "Table 1: Conventions and definitions used in the description of the distributed protocol." If there are gaps in the description, I will gladly augment it in the next version. We can discuss this in London too. A future version should also include the packet format. 5. When you say "ensures each domain's independent convergence to the correct bottleneck substructure graph without the need to know private flow and topology information from other domains. " , I am wondering whether you use PATH_METRIC_ANNOUNCEMENT to carry path metric information will expose some private flow and path information? We think the PATH_METRIC_ANNOUNCEMENT does not include private flow information. First because it does not operate at a flow level, it operates at a path level. Secondly, because the only parameter shared is a scalar value that reflects "available bandwidth on that path" according to the current bottleneck structure. Happy to discuss more in London during IETF week. Looking forward to it. Thanks, Jordi ________________________________ From: alto <[email protected]> on behalf of Qin Wu <[email protected]> Sent: Wednesday, November 2, 2022 8:48 To: IETF ALTO <[email protected]> Cc: [email protected] <[email protected]> Subject: [alto] Bottleneck Structure Graphs in Multidomain Networks WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi, Jordi: Thank for writing this draft, to tackle multi-domain setting issue, if my understanding is correct, what you propose is to add new functionality to ALTO server and extend ALTO protocol. It is interesting topic, I think it is also related to what PANRG and COINRG are doing. 1. First Computation of Bottleneck Substructures is computation intensive, which might require in network computing support. 2. The multi-domain setting has been documented in ALTO deployment RFC, see quoted text: " 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. " 3. When you say the distributed protocol proposed in this document could be used as a use case to help drive the specifications of the inter-server communication protocol discussed in [I-D.draft-zhang-alto-oam-yang], I am not sure we should couple the distributed protocol you proposed with server to server communication. I think ALTO OAM is positioned to integrate various different tools to capture network data, oam data, flow data, build network map and cost map. Existing protocol can be used, such as routing protocol, OAM protocol, IPFIX, do you want to propose to use ALTO to define such distribute protocol? why BGP is not sufficient? Also distribute information across domain has a big security concern, how do you address this? 4. Let's take a close look at PATH_METRIC_ANNOUNCEMENT, what packet format looks like? what parameters are carried in PATH_METRIC_ANNOUNCEMENT? 5. When you say "ensures each domain's independent convergence to the correct bottleneck substructure graph without the need to know private flow and topology information from other domains. " , I am wondering whether you use PATH_METRIC_ANNOUNCEMENT to carry path metric information will expose some private flow and path information? Happy to discuss more in London during IETF week. -Qin
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
