Session Date/Time: 03 May 2023 14:00

ALTO

Summary

This interim ALTO Working Group meeting focused on identifying potential data sources for ALTO and presenting proposals for their integration. The discussion aimed to foster ALTO development by leveraging readily available and widely deployed data sources. Key topics included a survey of potential data sources, a proposal for integrating BGP Communities, an update on using BGP-LS for ALTO map generation, and a proposal for extending ALTO to incorporate compute resource information.

Key Discussion Points

Meeting Objective: The chairs, Qing and Mohammed, outlined the goal of the meeting: to identify and discuss how to integrate data sources that are already operational and widely deployed to foster ALTO development. The focus was not on enumerating all possible data sources but on those with existing deployments.
Survey on Potential Data Sources of Interest (Luis and Judy):
- Luis presented a survey identifying useful data sources and their potential impact on ALTO artifacts (Network Map, Cost Map). The framework considered how to collect, process, and present the data.
- Data Sources discussed:
  - Topology: IETF Network Topology and IETN network topology, impacting the Network Map and potentially the Cost Map (with traffic engineering info).
  - Performance Metrics: Existing draft defines how to present, but collection and integration methods (e.g., via BGP-LS or IGP) need analysis, impacting the Cost Map.
  - Compute Resources: Information on available compute resources in the network, distinct from service function resources. Impacts Network Map (extending topology) and Cost Map (new metrics).
  - Service Functions: Information on network functions, applications, or services, including their location and allocated resources. Impacts Network Map and Cost Map, with synergy with the CATS WG.
  - Available Bandwidth: Information on path bandwidth to aid flow placement decisions. Primarily impacts the Cost Map.
  - Energy Consumption Metrics: Power consumption data in paths, aligning with IETF interest in "green metrics." Impacts the Cost Map as an additional metric.
  - Inventory Information: Examples included geolocation of nodes to enrich the Network Map (relevant to geofencing, trusted network activities).
  - Planned/Scheduled Variation of Routing: Link with TBR WG, BGP IP pools (e.g., CGNAT, APNs) for prefix declarations.
- Discussion:
  - Qing suggested adding a column to the survey to indicate if a data source has open-source projects or existing implementations by vendors/operators (e.g., BGP, network topology in OpenDaylight). He also suggested considering BGP-LS.
  - Daniel (Telefónica) mentioned their existing components (e.g., a "current gene") that collect control plane information, including iBGP, from router reflector connections, which could inform collection processes.
Proposal for Data Source Integration: BGP Community (Luis):
- Proposal: To evolve ALTO to work with BGP communities, which operators use for handling and identifying sets of prefixes (e.g., for billing, local preference).
- Rationale: BGP communities aggregate prefix information, similar to PIDs, but their relationship can be one-to-one, one-to-many (e.g., a BGP community for a region aggregating multiple PIDs), or many-to-one (e.g., one PID aggregating different communities for fixed and mobile users).
- Impact: Determine Network Map and Cost Map for BGP communities, expanding ALTO's visibility.
- Discussion:
  - Richard asked about specific protocol suggestions for ALTO and potential BGP extensions. Luis noted the need to modify the ALTO protocol for requesting BGP communities and handling their aggregation, potentially requiring defining performance metrics for regions.
  - Qing questioned if BGP communities would provide finer-grained PIDs or introduce a new type of endpoint group, possibly requiring extensions to endpoint-map or entity-map.
  - Seven requested more formal examples to illustrate the limitations of current PID definitions and justify the need for BGP community integration, especially regarding geographical regions and subdivisions.
Proposal for Data Source Integration: BGP-LS (Jason and Seven):
- Progress Update: Summarized experience and practices using standard BGP-LS in an implementation (OpenDaylight BGP plugin) to generate ALTO maps.
- Approach:
  - Routers connect to route reflectors where BGP-LS is configured.
  - ALTO server acts as a data source listener, collecting BGP-LS information (route updates, link-state announcements).
  - Network Map generation uses AS number and prefix information.
  - Cost Map generation uses BGP-LS link-state announcements (node, describing prefix/AS, link metrics), running link-state routing algorithms (OSPF, ISIS) to compute end-to-end routes and map APIDs to cost metrics.
- Challenges for Multi-AS Scenarios: Determining Ingress points, inter-AS information exchange (requiring extensions), and data encoding (YANG data model for BGP-LS from OpenDaylight experience).
- Discussion:
  - Richard questioned the accuracy of BGP-LS in real-life scenarios with traffic engineering overlays overriding IGP shortest paths.
  - Ronan (operator perspective) affirmed the interest in traffic engineering for load distribution/balancing (e.g., ECMP) and saw value in ALTO providing additional network exposure information for dedicated routing requirements beyond general traffic distribution.
  - Qing suggested focusing on how BGP-LS information (topology, link state) can be mapped and translated into ALTO Network Maps and Cost Maps, and the potential for a BGP-LS YANG data model.
Proposal for Data Source Integration: Compute (Jodi):
- Motivation: Extending ALTO to support compute information (CPU, GPU, memory, storage) is critical for edge computing applications (XR, AI, IoT) to optimize workload placement decisions.
- Approach: ALTO is well-positioned as a neutral API to expose this information. The proposal leverages existing APIs, including SDO standards (ETSI MEC, DMTF CNTT) and de facto standards (Kubernetes, OpenStack).
- Synergy: Noted clear synergy with the CATS working group to avoid duplicating efforts. The "Service Edge" draft was highlighted as relevant.
- Discussion:
  - Qing emphasized coordinating with the CATS WG and suggested incorporating more details on the investigated open-source tools for gathering compute information into the draft.

Decisions and Action Items

All Proposers: Take further discussion of their proposals, including addressing questions raised, to the ALTO mailing list.
Luis and Judy: Consider adding a column to the data source survey to indicate existing open-source implementations or operator/vendor deployments for each data source.
Luis (BGP Communities): Provide more formal examples to justify the limitations of existing PID mapping and clarify the specific impact on ALTO protocol and artifacts on the mailing list.
Jason and Seven (BGP-LS): Continue discussions on the mailing list, focusing on the mapping of BGP-LS data to ALTO Network Maps and Cost Maps, and the potential for defining a BGP-LS YANG data model.
Jodi (Compute): Incorporate more details on open-source tools for gathering compute information into the "Service Edge" draft and ensure close coordination with the CATS Working Group.
Geofang: Post his proposal (not presented due to time) to the mailing list for discussion.

Next Steps

Discussions on all proposals, particularly concerning the detailed technical aspects, mapping to ALTO artifacts, and potential protocol extensions, will continue on the ALTO Working Group mailing list. Coordination with other relevant WGs (e.g., CATS, TBR) will be pursued as needed.