Re: [alto] Discussion on the future of ALTO WG

[LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>]

Hi Med, Qin,

Thanks for triggering this discussion.

I will comment on Proposal #1, but not sure if part of my comments could be considered as related to Proposal #2.

I think that supporting ALTO operations is certainly needed. As long as we are having operational experience is evident that some additional work is needed. And also, some additional work is identified as convenient because of the new types of services that are being demanded if compared with the past. Let me please explain my arguments.

My first comment is on security. All aspects related to security required of additional work due to the criticality of the information being exposed. For instance, how to avoid the inference of sensible network information from the analysis of the values of the PID identifiers; or ways of isolating ALTO servers from potential attackers acting as clients e.g. by means of pub/sub schemes, to mention a couple of examples. Security is an important missing piece on ALTO specs, worthy to be developed. These situations are emerging now as consequence of deployment experience in real networks, so addressing real situations. There are some other areas of work related to deployments, but not to security, which are important as well, such as ALTO redundancy/protection, frequency of topology updates (i.e. freshness), etc, that can be relevant to consider, as well.

Second comment is on other ways of consuming ALTO information. For example, existing ALTO specs relay on PIDs for building network and cost maps. However, in operators' networks is extremely common to work with BGP communities as grouping of prefixes with a common purpose. Thus, it seems convenient to bring the idea of BGP communities into ALTO [1]. Note that the scope of a BGP community can differ from the scope of a PID (e.g., the BGP community representing a set of prefixes sharing a common characteristic other than the topological one). Note as well that the concept of BGP community is tightly related to the definition and application of policies. So, I guess you can perceive the potential of combining the information provided by ALTO (network + cost map+ further information such as performance metrics [2]) together with the network policies by means of BGP communities.

Third comment is on multi-domain. This is very sensible for operators. The vast majority of services today imply multi-domain setting. Just as an example, around 70 - 80% of traffic today in operators' network is coming from OTT services (video streaming, gaming, social networks, hybrid clouds, etc). This is intrinsically multidomain because content providers are different administrative domains, and in some cases there is the need of traversing intermediate domains for accessing contents. The role of multi-domain ALTO can be key for achieving a more efficient service delivery, end-to-end. And because this multi-domain nature, having standardize solutions is key for lowering integration time, costs and efforts. Defining common syntax and semantics of the interchanged information across domains is fundamental [3].

Fourth is on additional operational situations where ALTO can assist on simplifying the operation and improving the overall target of automation in service provider networks. Just as a couple of examples. Let's consider for instance the complexities generated in terms of keeping up-to-date network and cost maps for pools of prefixes being dynamically allocated in different parts of the network. In some cases, this is favored by the control-user plane separation (CUPS) approach, in some other cases because of the allocation of pools for CGNAT, or for APNs in the mobile network, etc. All of this dynamicity is difficult to track and keep updated, so ALTO can become an essential piece for an up-to-date view and operation of this complexity. Another example is represented by the proposition from the Fujitsu colleagues in ALTO in respect the consideration of geolocation information within the ALTO network and cost maps [4]. This is relevant not only for the trust-related scenarios as originally identified by Fujitsu, but also because it can be an enabler for other important operational cases such as the ones related to GPDR enforcement [5], which imposes obligations to operators.

Finally, having in mind the value of ALTO for operations, I think it is unavoidable to consider new capabilities originated by operational situations not present in our networks some years ago. Let me briefly refer to the exposure of additional information with topological relevance, for instance the one related to compute. As we all know, there is a new WG named CATS addressing part of the problem space related to the consideration of compute information. It is relevant to remark the "TS" part (i.e., traffic steering) since it implies that there are already in place some functions/applications where to steer the traffic, with the decision being internal to the network by operator's nodes. For the big problem space of compute-related information there are yet important parts not covered by CATS where ALTO has an essential role. Let me just mention a few: one is the exposure of compute-related information towards applications, where the applications are the ones taking decisions based on such information (not the network nodes); a second one, the addressing of scenarios where topological information of the available infrastructure is relevant for taking decisions, such as service function placement (i.e., there are not yet functions deployed -so no possibility of steering anything- but the information is yet needed for placement decisions); etc (there are others, such as the multidomain view, etc, but don't want to create an extremely long mail).

In summary, and from the perspective of an operator like Telefonica: ALTO is becoming an extremely important piece for automation of network operations in with respect to the exposure of information toward services/applications (both internal and external). There are real operational situations identified that can benefit from the maintenance and extensions of ALTO requiring different degrees of work. And there is now an industrial momentum realizing the need of further exploring further integration/interaction between applications and networks [6]. ALTO is the best positioned IETF development for playing the role of IETF "Network Exposure Function" that can provide necessary information from the network (in IETF sense) to applications (either external or internal) or to different overlay networks (CDN, 3GPP, SD-WAN, etc) relaying on top of the IETF network. Up to now we as a group have had some propositions in "dormant" state waiting for the chance of a new charter that could allow to develop them. Some other propositions are derived from the deployment work that helps to identify missing pieces. This discussion arrives in the proper moment for taking all those propositions into consideration and scope the work in those directions.

Thanks again for triggering the discussion, and apologies for the long mail

Best regards

Luis

P.S. After reading Jordi's mail, I think his "Proposal #3: Support ALTO extension for the new industry needs" is a very valid option to consider, giving room to fix identified limitations but also allowing to incorporate new capabilities justified by needs coming for new forms of services and applications.

[1] https://datatracker.ietf.org/doc/html/draft-contreras-alto-bgp-communities-00
[2] https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/
[3] https://datatracker.ietf.org/doc/html/draft-lachos-alto-multi-domain-use-cases-02
[4] https://www.fujitsu.com/global/documents/about/research/article/202212-trust-enhanced-networking/trust_enhanced_networking_whitepaper_en.pdf
[5] https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
[6] https://www.ietf.org/archive/id/draft-iab-path-signals-collaboration-03.txt

De: alto <[e-mail]> En nombre de [e-mail]
Enviado el: miércoles, 22 de marzo de 2023 9:09
Para: IETF ALTO <[e-mail]>
CC: Qin Wu <[e-mail]>
Asunto: [alto] Discussion on the future of ALTO WG

Hi all,

As the WG is about to finalize the last chartered items, we would like to have a discussion on the future of the WG with all of you. We will also have a slot during the IETF#116 meeting on this matter. The plan is to let this discussion open for the coming two months (i.e., ** till end of May **).

Please note that we are also planning to organize a set of interims (mostly in replacement of the weekly meetings). Announcements should follow soon.

Together with Qin, we discussed the following two options:

# Proposal # 1: Support ATLO Operations
## Rationale

  *   Many I-Ds are being proposed to ALTO.
  *   Some deployments/products are being disclosed.
  *   Having a referent WG is a signal that the IETF is ready to support operations and fix flaws/limitations that will be reported.
  *   ALTO integration complications were out of the scope. Documenting those with a set of deployment choices may be a helper for other deployments.
  *   There is constant engagement and dedication of a core team to deliver ALTO specs.
## Proposed direction of work

  *   Recharter the WG with a focus on ALTO maintenance and integration with data sources. Dedicated YANG modules will be produced.

# Proposal # 2: Revitalize ALTO
## Rationale

  *   Some of the proposed ALTO work is research-oriented (PANRG, would be more appropriate for some items), while other may be conducted in new WGs (e.g., CATS).
  *   Some of the key foundations of ATLO might not be valid after 15 years.
  *   Closing the WG is not a failure, but a sign of ALTO specification maturity.
  *   Revitalizing the ALTO effort is thus needed.
## Proposed direction of work

  *   Consider closing ALTO right after the completion of OAM/Transport items.
  *   Move ALTO maintenance to TSVWG.
  *   Use the ALTO/TSVWG mailing lists to socialize deployment experience.
  *   Based on the maintenance that might be shown in TSVWG and shared deployments, reassess the interest of the community in enriching ALTO with additional features by organizing a formal BoF.

We are seeking for the WG feedback/preference for each of these two options. Specifically, feel free to challenge the rationales above, propose concrete action items for #1, disclose ALTO products developments you are aware of, etc.

Absent sufficient engagement, the ** default that the Chairs will formally discuss with our AD is Proposal #2 **.

FWIW, we expect this discussion to be an input for Martin, as we do have the following in the current charter:

  Furthermore, the Area Director and chairs will assess the state of the
  deliverables at the end of 2022. If the Area Director judges that delivery of
  these documents is not imminent, and that documentation of wide deployment is
  missing, the AD may close the working group immediately.

Thank you.

Cheers,
Qin & Med

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição