Re: [irs-discuss] About ALTO Vs. BGP-LS

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

Hi Volker,

On 8/3/12 12:02 PM, Volker Hilt wrote:
>
> I believe that the capability to provide a simplified view on the 
> network topology to an application is a key feature rather than a bug. 
> Applications that want to have a view on network topology don't need 
> need a fine grained view on the topology in most casts and benefit 
> from having an abstracted view. This will simplify processing for the 
> application and enables providers to control the exposure of details. 
Agreed.

> We've seen some numbers for topology data sizes in the incremental 
> updates presentation in the ALTO meeting, which provide some insights 
> into the amounts of data needed for different topology sizes.
>
> I like the idea of enabling an ALTO server to offer different levels 
> of details. This will enable a server to tailor responses to the 
> specific client. It will add complexity as the ALTO server itself will 
> have to maintain the most complex topology it is offering and will 
> have to keep this topology up to date. But this is an interesting 
> question for discussion in the WG.
>
Glad that you also like the idea of different levels of details of the 
network topology. If the ALTO Server is given a detailed topology 
(constructed from multiple sources, such as routing feed, LSP feed, 
configuration files), we can offer multiple topology 
operators/aggregators to explore the detailed topology, according to 
need and policy. A simple example operator is level (i.e., hierarchy 
such as at the area level), but one might specify other operators (e.g., 
fisheye focus). There are studies on representation of multi-level 
graphs that we can try to take advantage of. This can be a subject for 
the group to explore.

We may need to study/collect use cases for multiple level topology. One 
interesting example immediately coming to mind is the Abstract Node 
concept (specify IP prefix/ASN) used in RSVP-TE.

Cheers,

Richard

> Cheers,
>
> Volker
>
>
>
>
>
>
>
> On 03.08.2012 11:03, Y. Richard Yang wrote:
>> Hi Stefano,
>>
>> Good post! I added the ALTO mailing list, given the relevance. I hope
>> that this is OK cross posting.
>>
>> First, a few comments on ALTO:
>>
>> View granularity:
>>
>> - ALTO currently defines two abstract network topology data structures:
>> Network Map and Cost Map(s). More link-state oriented maps (graphs),
>> with aggregations and transformations, can be added efficiently to ALTO.
>> Some initial efforts are already on the way (e.g., see the graph
>> representation proposal at page 9:
>> http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence,
>> I see a natural next-step is for ALTO to provide a link-state view to
>> external entities.
>>
>> - It is a good comment on the level of details that ALTO should
>> delivery. This is a good question for the ALTO working group and the
>> community to discuss. I feel that ALTO should provide multi-levels of
>> granularity of views, and we should discuss in the working group.
>>
>> Pull vs push delivery mechanism:
>>
>> - There are more discussions on adding the incremental update in ALTO.
>> Multiple mechanisms have been discussed. I feel that it is the right
>> direction for ALTO.
>>
>> Now let me understand the deployment model of BGP-LS. Your explanation
>> on the issues of acquiring routing state is excellent. Let me start by
>> understanding more details on the deployment model of BGP-LS inside a
>> network:
>>
>> - A set N_igp of BGP-LS instances are deployed to collect IGP info. You
>> need multiple instances because IGP needs direct connectivity
>> (adjacency). Each instance here receives (potentially multiple) IGP
>> updates and streams (relays) to an another (remote) entity, which I
>> assume is a master BGP-LS instance. So each of these N_igp instances is
>> IGP-in and BGP-LS out. This appears to be shown in Figure 1 of
>> draft-gredler-idr-ls-distribution.
>>
>> - A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You
>> also may need multiple instances because the network does not want to
>> see aggregated states but raw states. These instances will feed to the
>> master BGP-LS as well.
>>
>> - The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some
>> direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to
>> use: for example, an ALTO Server transforms/aggregates the feed to
>> generate ALTO views (maps and graphs), and an PCE uses the feed to
>> maintain its TED. One could even imagine that ALTO builds a detailed TED
>> and feeds to PCE, but this beyond the scope of this discussion. The
>> master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the
>> master BGP-LS does not push to any other entities and simply maintains
>> an internal DB for others to query.
>>
>> Do I understand it correctly?
>>
>> Now, we can take a look at more specifics of BGP-LS.
>>
>> A first perspective is the semantics of the content. If the objective is
>> to solve the aforementioned deployment issue, then an alternative
>> solution is to introduce a simple LS update tunneling protocol, where a
>> link-state proxy forwards LS messages to a collector. The current design
>> of BGP-LS starts with such a feeling (i.e., an NLRI starts with the
>> Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2,
>> OSPF, etc). However, the protocol appears to (try to) go beyond simple
>> tunneling and introduces a common LS schema, by converting/filtering
>> individual IGP LS messages to some common format. I feel that it can be
>> helpful to first specify the schema (LS data model) instead of the
>> specific encoding. For example, OSPF specifies LS Age, and this is
>> filtered. (Please correct me if I missed it). On the other hand, one can
>> think that some Age info can be helpful for one to understand the
>> "freshness" of the LS. A problem studied in database is heterogeneous
>> databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single
>> schema, and there can be many problems. If there is such a study, please
>> do share a pointer.
>>
>> A second perspective is using BGP as the transport. What key features
>> from BGP do we really need (yes, weak-typed TLV encoding offers a lot of
>> flexibility)? What features of BGP do we not need (e.g., BGP is a
>> routing protocol and hence builds in features to handle convergence such
>> as dampening)? What may be missing (e.g., a capability of pull or
>> filtering of push). I feel that these issues should be discussed. If
>> they have already been discussed, please do share a pointer, as I am
>> definitely a new comer.
>>
>> Thanks!
>>
>> Richard
>>
>> On 8/2/12 11:54 PM, stefano previdi wrote:
>>> All,
>>>
>>> as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few
>>> things:
>>>
>>> ALTO has been designed in order to deliver to applications (through
>>> http/json):
>>>
>>> 1. two maps representing the network topology in an abstracted view
>>> (or set of views through multiple maps). The map does not include
>>> the details of a link-state database and therefore have little use
>>> for any element that would need to retrieve from the network the
>>> detailed/complete network layer topology, for example: link
>>> addresses or link BW resources, etc. IOW: ALTO maps do not have
>>> the granularity of a link-state database and ALTO protocol is not
>>> designed to deliver such details.
>>>
>>> and/or
>>>
>>> 2. Ranking services where a client sends a bunch of IP addresses in
>>> a message and the ALTO server replies by ranking these addresses
>>> based on their topological/network distance (or whatever criteria
>>> the ALTO server has been configured for). This is called: Endpoint
>>> Cost Service.
>>>
>>> When using ALTO maps, and the ALTO protocol being http/pull based,
>>> there's no such concept of unsolicited routing updates. An ALTO
>>> client is typically a browser that will pull the maps from an ALTO
>>> server using http. The ALTO server will make no effort to ensure the
>>> client has the latest view of the topology (i.e.: It's the role of the
>>> client to poll for new maps time to time).
>>>
>>> Now, in order for an ALTO server to deliver Maps or Ranking services,
>>> it needs to build some form of topology and in order to achieve this,
>>> it needs somehow to be fed by either the operator (configuration) or
>>> to receive dynamically topology information from the network (e.g.:
>>> ISIS/OSPF/BGP).
>>>
>>> Here we had two options:
>>> 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies
>>> to ABRs or L1L2 routers in each area so to retrieve the LSDB from
>>> each area. In practice I know no SP willing/accepting to open their
>>> IGP to an ALTO server. Also, IGP requires direct connectivity
>>> (adjacency) so from an operation point of view is complex and not
>>> desired.
>>> 2. Use a database distribution protocol running on top of a reliable
>>> transport layer that would allow an ALTO server to connect to a
>>> _single_ and _remote_ Route Reflector (i.e.: no need to be directly
>>> connected) and grab the whole network topology that will be updated
>>> using standard routing protocol mechanisms (i.e.: routing updates)
>>> and that would allow the operator to control (through policies and
>>> filters) what to distribute and to which server.
>>>
>>> Benefits: single (or dual at most for redundancy) connection for
>>> the ALTO server (rather than having a direct adjacency with each
>>> ABR) and, from the operator perspective, single point of
>>> distribution of network topology (easier to apply policies and
>>> control what you deliver). This is what BGP-LS is about.
>>>
>>> BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey
>>> link-state and, more generically, any type of topology information.
>>> The draft specifies NLRI and attributes that map whatever you can
>>> find in a link-state database.
>>>
>>> We currently have draft-gredler-idr-ls-distribution in the process
>>> (hopefully) to be adopted as WG item in IDR WG (so far we 're getting
>>> good support). We also have 3 implementations of BGP-LS.
>>>
>>> Deployment-wise: BGP-LS is not yet deployed, however, we already have
>>> deployments (I know at least two) where an ALTO server retrieves IP
>>> prefix information from remote BGP RRs (for ipv4). The same scheme
>>> will be used once BGP-LS will be deployed (so to say that it is not
>>> something that we invented after a couple of beers but corresponds to
>>> requirements for delivering network services to upper layers while
>>> still controlling efficiently what you distribute, to whom and in
>>> which form (note that, often, beers are anyway part of the process).
>>>
>>> More information here:
>>> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02
>>> http://tools.ietf.org/html/draft-ietf-alto-protocol-12
>>>
>>> Hope this helps.
>>>
>>> s.
>>>
>>>
>>>
>>> On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote:
>>>> Tom,
>>>>
>>>>> I agree that one of the top work items for this effort should be a
>>>>> standardized topology function, and one that is accessible via a
>>>>> non-routing protocol.
>>>> So if the requirement is to have topology export via non-routing
>>>> protocol then I think we should seriously revisit or repackage the
>>>> draft-gredler-idr-ls-distribution-01 which works for for both OSPF
>>>> and ISIS.
>>>>
>>>> However before that let's really understand the requirement why it
>>>> must be exported via non-routing protocol .... Keep in mind that just
>>>> to parse BGP UPDATE messages and retrieve interesting pieces out it
>>>> it requires very little code rather then full BGP implementation.
>>>>
>>>> The particular feature I like about
>>>> draft-gredler-idr-ls-distribution-01 is that it is read-only ;)
>>>>
>>>> R.
>>>>
>>>>> I agree that one of the top work items for this effort should be a
>>>>> standardized topology function, and one that is accessible via a
>>>>> non-routing protocol. While not exactly "low hanging fruit", it is
>>>>> something that (to me) is a clear work item with clear goals that
>>>>> should
>>>>> be tackled straight away.
>>>>>
>>>>> --Tom
>>>>>
>>>>>
>>>>>
>>>>> On 8/2/12 3:24 PM, "James Kempf" <[e-mail]> wrote:
>>>>>
>>>>>> So after seeing part of Alia's talk this morning (I had to leave in
>>>>>> the
>>>>>> middle unfortunately), I'd like to make a couple suggestions. There
>>>>>> were
>>>>>> a lot of ideas presented in the talk, enough for an entire IETF
>>>>>> Area. I
>>>>>> think to make tangible progress, the work needs to be focussed on a
>>>>>> small
>>>>>> subset that would be of immediate interest and usability.
>>>>>>
>>>>>> There are a couple areas that suggest themselves, but one that
>>>>>> would be
>>>>>> useful in work that I've been involved in is a standardized 
>>>>>> format for
>>>>>> network topology representation and a protocol for exchanging it. 
>>>>>> The
>>>>>> Onix OpenFlow controller has a network information base with a
>>>>>> specialized format for network topology, and every OpenFlow 
>>>>>> controller
>>>>>> requires this. Having a standardized way to represent it might
>>>>>> foster a
>>>>>> common topology database package. Another application is network
>>>>>> management. Every network management system needs some kind of
>>>>>> topology
>>>>>> representation. Finally, though I am not an expert in PCE
>>>>>> construction,
>>>>>> it would seem to me that a PCE would need some kind of topology
>>>>>> representation in order to perform path calculations. Having a 
>>>>>> way,for
>>>>>> example, for the OpenFlow controller and the PCE to exchange 
>>>>>> topology
>>>>>> information would be really useful. I would say to start with 
>>>>>> physical
>>>>>> topology because that is fundamental, but make the format flexible
>>>>>> enough
>>>>>> to support
>>>>>> virtual topology representation.
>>>>>>
>>>>>> jak
>>>>>> _______________________________________________
>>>>>> irs-discuss mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>
>>>>>
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/irs-discuss