Hi, Richard, Luis: 发件人: alto [mailto:alto-boun...@ietf.org] 代表 Y. Richard Yang 发送时间: 2023年6月27日 21:00 收件人: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmuri...@telefonica.com> 抄送: IETF ALTO <alto@ietf.org> 主题: 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 <y...@cs.yale.edu<mailto:y...@cs.yale.edu>> 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 <luismiguel.contrerasmuri...@telefonica.com<mailto:luismiguel.contrerasmuri...@telefonica.com>> 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
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
