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

[Greg Bernstein <[e-mail]>]

Hi Richard, Stefano, et. al. thanks for the explanations and pointers to 
the BGP-LS draft. This helps avoid any confusion that BGP-LS is in 
competition with ALTO.

BGP-LS (http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02) 
could be used to feed topology/path information to ALTO servers or path 
computation elements (PCE).  As part of that process it would collect 
link state information from IGPs and possibly abstract it.

One partial point of confusion for me as a non-BGP speaker ;-)   was in 
the BGP-LS abstract which stated "In a number of environments, */a 
component external to a network/* is called upon to perform computations 
based on the network topology and current state of the connections 
within the network, including traffic engineering information."  or  
"This document describes a mechanism by which links state and traffic 
engineering information can be collected from networks and *shared with 
external components* using the BGP routing protocol."
I always considered PCE clients and servers as being within the network 
(working with privileged or sensitive network information) and an ALTO 
server as abstracting that information for use by network clients.  I 
guess by "external" to the network meaning was external to the "data plane".

I also noticed some parallels with our ALTO large bandwidth 
use-case/modeling work (section 6 of 
http://tools.ietf.org/html/draft-bernstein-alto-large-bandwidth-cases-02) and 
BGP-LS. In particular we both seem to want graph and path abstractions.  
For path abstractions (aggregation) we needed (due to bandwidth 
constraints) model a path as one or more abstract links with appropriate 
properties.  It seems a similar situation would hold when trying to 
aggregate paths with SRLG properties. These similarities make sense 
since both drafts are concerned with sharing information about the 
network in an aggregated/abstract form.

Best Regards
Greg B.


On 8/3/2012 11:46 AM, Y. Richard Yang wrote:
> Hi,
>
> Sue suggested that I forward this email to idr for more discussions.
>
> Thanks.
>
> Richard
>
> On 8/3/12 11:24 AM, Susan Hares wrote:
>> Richard:
>>
>> Could you cross-post this note to the [e-mail] list. The BGP-LS 
>> draft is being considered for WG adoption. I think this perspective 
>> would help the idr WG.
>>
>> Thank you,
>>
>> Sue
>>
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Y. Richard Yang
>> Sent: Friday, August 03, 2012 11:04 AM
>> To: stefano previdi
>> Cc: Thomas Nadeau; James Kempf; IETF ALTO; [e-mail]; 
>> [e-mail]
>> Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS
>>
>> 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
>> deliver. 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
>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>
>


-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]