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

Volker Hilt <volker.hilt@bell-labs.com> Tue, 07 August 2012 11:17 UTC

Return-Path: <volker.hilt@bell-labs.com>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8C821F86A4; Tue, 7 Aug 2012 04:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.649
X-Spam-Level:
X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz0kY+SW9f7W; Tue, 7 Aug 2012 04:17:03 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4804C21F86A2; Tue, 7 Aug 2012 04:17:03 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q77BGs5V020020 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Aug 2012 13:16:56 +0200
Received: from [149.204.61.15] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Aug 2012 13:16:55 +0200
Message-ID: <5020F926.707@bell-labs.com>
Date: Tue, 7 Aug 2012 13:16:54 +0200
From: Volker Hilt <volker.hilt@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "Y. Richard Yang" <yry@cs.yale.edu>
References: <CC404D94.2D5D%tnadeau@juniper.net> <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> <501C2047.1000100@bell-labs.com> <501C3999.3080804@cs.yale.edu>
In-Reply-To: <501C3999.3080804@cs.yale.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Cc: idr@ietf.org, robert@raszuk.net, irs-discuss@ietf.org, James Kempf <james.kempf@ericsson.com>, IETF ALTO <alto@ietf.org>, Thomas Nadeau <tnadeau@juniper.net>, stefano previdi <sprevidi@cisco.com>
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 11:17:05 -0000

Richard,
>>
>> 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.
>
Yes, I agree - this is an interesting area to explore. Another operator 
could be a view for a specific use, e.g., a view for CDN use. The 
operator can then populate this view with the desired abstraction level 
and policy.

> 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.
>
Indeed.

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" <james.kempf@ericsson.com>; 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
>>>>>>> irs-discuss@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>> _______________________________________________
>>>>>> irs-discuss mailing list
>>>>>> irs-discuss@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> irs-discuss@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> irs-discuss@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> irs-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/irs-discuss