Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links

["Y. Richard Yang" <[e-mail]>]

Hi Luis, Qin,

Good discussions. I see several good points:
-  "... explore how node, link information combing with next hop
information, inter-AS link information carried in BGP-LS is transformed
into network map, cost map, property map, etc, performance data which is
related to cost map."
- "... operators use BGP communities quite often as mechanism for applying
policies and determining certain behaviors on the IP addresses grouped in
the form of communities. This seems quite useful as well at the time of
exposing associated information (metrics, topology, etc) as enabled by
ALTO." In particular, we see BGP as a framework for policy checking and
recursive information propagation with policy control.

Given above, here are a few discussion points. The focus is on supporting
ALTO deployment; that is, how to obtain ALTO-needed information from BGP as
a carrier.

- Use BGP communities to propagate ALTO cost metrics, for subnet, as
a generalization of BGP propagating AS PATH
One main data source issue in ALTO is to compute the total cost of a cost
metric end-to-end, from a source to a given destination. Such information
can be propagated using BGP denoted as BGP communities. The propagation
will be recursive (cascading) to take advantage of BGP. BGP policies can be
used to adjust the propagated values. Ideally, the information is between
on-path BGP routers to achieve well-defined semantics:
- the BGP node of the destination AS announces the initial cost metrics
using BGP communities to a subnet prefix;
- the metrics are sent upstream to the next hop BGP peer, which applies
policy to decide, for each metric and each upstream, how to compute the
update aggregated metric (AS path is a special case of pre-pending ASN),
whether/when the info can be propagated (export policy).

Looking at the current set of ALTO performance metrics, we can see that
hoop count as additive; one-way delay, roundtrip delay, and delay variation
as additive as a starting point; residual bw, available bw as min. The tput
metric can be harder to compute and can be a topic for further
investigation.

There can be concerns for the model, both on protocol (scaling) and on
content (privacy). For protocol scaling, the information will be more
dynamic than AS path, and hence there is the concern of overhead. We can
limit the information for chosen subsets; for content, BGP policies appear
to be a great tool, but we should look into the details.

- Use BGP community from upstream to downstream to support cascading ALTO
I always feel that BGP is the right place to allow an upstream peer to
notify a downstream peer whether the downstream's announcement (proposal)
is accepted. This can be a good protocol design than depending on inference
or measurements (e.g., see which inter-AS links carry the traffic). Is it
already proposed? If so, such info can be exposed to ALTO to allow building
a more complete ALTO system.

These comments are particularly interesting:
- "... need to maintain these two separate sessions to create the network
and cost map for BGP community reachability"
- "... a BGP community can span more than one physical location, thus
probably new kind of cost metrics need to be elicited for characterizing
the cost map"

For the second case, how about cost vectors providing only partial order?
That is, we do not aggregate the raw metrics (e.g., routingcost) if it is
not possible (e.g., the two physical locations do not have a single
policy), and provide the vector; it is a bit like BGP path has SET. Make
sense?

Richard


On Sun, Jul 9, 2023 at 11:48 AM LUIS MIGUEL CONTRERAS MURILLO <
[e-mail]> wrote:

> Hi Richard, Qin,
>
>
>
> Apologies for the late answer.
>
>
>
> In the particular case of Communities, we are identifying some logical
> grouping of prefixes from end-users attached to the operator’s network.
> This is done within conventional BGP sessions. On the other hand, with
> BGP-LS we are obtaining the topological information that allows to derive
> the view of how those prefixes can be reached.
>
>
>
> In summary, we need to maintain these two separate sessions to create the
> network and cost map for BGP community reachability. This is an interesting
> problem since a BGP community can span more than one physical location,
> thus probably new kind of cost metrics need to be elicited for
> characterizing the cost map. I think this can be an interesting work to be
> discussed by the WG in future work.
>
>
>
> Best regards
>
>
>
> Luis
>
>
>
> *De:* Qin Wu <[e-mail]>
> *Enviado el:* jueves, 6 de julio de 2023 4:52
> *Para:* Y. Richard Yang <[e-mail]>; LUIS MIGUEL CONTRERAS MURILLO <
> [e-mail]>
> *CC:* IETF ALTO <[e-mail]>
> *Asunto:* RE: [alto] Topic B - maintenance of ALTO protocol // RE: June
> 20, 2023 meeting minutes and discussion working links
>
>
>
> Hi, Richard, Luis:
>
>
>
> *发件人**:* alto [mailto:[e-mail] <[e-mail]>] *代表 *Y.
> Richard Yang
> *发送时间**:* 2023年6月27日 21:00
> *收件人**:* LUIS MIGUEL CONTRERAS MURILLO <
> [e-mail]>
> *抄送**:* IETF ALTO <[e-mail]>
> *主题**:* Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20,
> 2023 meeting minutes and discussion working links
>
>
>
>
>
>
>
> On Tue, Jun 27, 2023 at 8:33 AM Y. Richard Yang <[e-mail]> wrote:
>
> Hi Luis,
>
>
>
> Thank you so much for starting this thread on Topic B. I feel that this is
> a crucial topic for the WG to investigate. Please see below.
>
>
>
> On Mon, Jun 26, 2023 at 5:18 PM LUIS MIGUEL CONTRERAS MURILLO <
> [e-mail]> wrote:
>
> Hi all,
>
> Related to Topic B on maintenance of ALTO, as a way of summary of what has
> been discussed during the last weeks, we could have two major sub-topics:
>
> 1/ extension of ALTO to consider operational simplicity. Here fits the
> proposal of introducing BGP communities in ALTO. The rationale is that
> operators use BGP communities quite often as mechanism for applying
> policies and determining certain behaviors on the IP addresses grouped in
> the form of communities. This seems quite useful as well at the time of
> exposing associated information (metrics, topology, etc) as enabled by
> ALTO. An initial draft can be found here:
> https://github.com/luismcontreras/alto-bgp-communities
>
> The plan is to generate version -01 for IETF 117.
>
>
>
> I like this subtopic! I have adopted a view that ALTO should be divided
> into 2 layers: a concept/abstraction layer and a transport layer built on
> top of the concept layer. I feel that there is great work validating the
> concept layer, for example, the concepts of distance, ranking, say in the
> flow director, padis work. For transport later, the WG can be flexible and
> provide multiple transport mechanisms. BGP communities are an excellent,
> well defined framework to serve as a transport (of both existing alto
> concepts/abstractions) and also existing networking abstractions). Good
> direction.
>
>
>
> To be specific, I think it will be a worthwhile effort to look into
> BGP-ALTO; that is, how to use BGP to encode, transport and update ALTO
> basic information. It can be considered a BGP vertical slice, with BGP-LS
> as the lower lower layer. Make sense? I will add some more details to the
> doc.
>
>
>
> Talk to many of you soon.
>
>
>
> [Qin Wu] As we know, BGP-LS is used to collect the network topology data,
> ALTO is used to expose the network topology information, RFC7752 has
> already provided
>
> ALTO and BGP-LS integration use case in figure 3:
>
>      +--------+
>
>      | Client |<--+
>
>      +--------+   |
>
>                   |    ALTO    +--------+     BGP with    +---------+
>
>      +--------+   |  Protocol  |  ALTO  | Link-State NLRI |   BGP   |
>
>      | Client |<--+------------| Server |<----------------| Speaker |
>
>      +--------+   |            |        |                 |         |
>
>                   |            +--------+                 +---------+
>
>      +--------+   |
>
>      | Client |<--+
>
>      +--------+
>
>
>
> Figure 3: ALTO Server Using Network Topology Information
>
>
>
> Network topology data carried in BGP-LS is modelled as node, link , prefix
>
> ALTO network information resource is modelled as Network map, Cost map,
> property map, entity property map,
>
> We need to explore how node, link information combing with next hop
> information, inter-AS link information carried in BGP-LS
>
>    Is transformed into network map, cost map, property map, etc,
>
>    I feel this is the missing pieces we take for granted, in addition, we
> need to consider how network topology can be correlated with other network
> data, e.g.,
>
> Performance data which is related to cost map.
>
>
>
>
>
> Richard
>
>
>
>
> ------------------------------
>
> 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
> ------------------------------
>
>
> Le informamos de que el responsable del tratamiento de sus datos es la
> entidad del Grupo Telefónica vinculada al remitente, con la finalidad de
> mantener el contacto profesional y gestionar la relación establecida con el
> destinatario o con la entidad a la que está vinculado. Puede contactar con
> el responsable del tratamiento y ejercitar sus derechos escribiendo a
> [e-mail]. Puede consultar información adicional
> sobre el tratamiento de sus datos en nuestra Política de Privacidad
> <https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>
> .
>
> We inform you that the data controller is the Telefónica Group entity
> linked to the sender, for the purpose of maintaining professional contact
> and managing the relationship established with the recipient or with the
> entity to which it is linked. You may contact the data controller and
> exercise your rights by writing to [e-mail]. You may
> consult additional information on the processing of your data in our Privacy
> Policy
> <https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>
> .
>
> Informamos que o responsável pelo tratamento dos seus dados é a entidade
> do Grupo Telefónica vinculada ao remetente, a fim de manter o contato
> professional e administrar a relação estabelecida com o destinatário ou com
> a entidade à qual esteja vinculado. Você pode entrar em contato com o
> responsável do tratamento de dados e exercer os seus direitos escrevendo a
> [e-mail]. Você pode consultar informação adicional
> sobre o tratamento do seus dados na nossa Política de Privacidade
> <https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>.
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>