Re: [irs-discuss] About ALTO Vs. BGP-LS
Alia Atlas <akatlas@gmail.com> Fri, 03 August 2012 23:57 UTC
Return-Path: <akatlas@gmail.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 B4FB021F8DAB; Fri, 3 Aug 2012 16:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-1.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
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 S3Qx6q1RsQr0; Fri, 3 Aug 2012 16:57:08 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6759B21F8D20; Fri, 3 Aug 2012 16:57:08 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so1563428ggn.31 for <multiple recipients>; Fri, 03 Aug 2012 16:57:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I8UdNKB+tzrwSGda7KkdpJXpW88WSKVjDkdJcVcvY2w=; b=YIjSNYBBgAf7zAQaSuGho7VbNYaYYqXio2Qv7NGq+RpBFxR4Ah03J/ldmw6Wy3vfnS vnmDbtn/JPxX7M+1owgPTurquZ8WbF3cciogRJbCf+NxY7YbfRj0KNpLS+wVOQELJdyl 3Y8lx6i5hC3R3YkRp5E8rAmbC/R+ijGSY4Iqdur8FRQT342+clWYZQyG8G+XRFQMjmtD 21G//YNMqlTn+SMO84vo0Pg7+IHWgiwkK2ibGKvgFXEbm3k7raDLKZUp0NtqdZ3wxPCU ifbQCTvLeL+Dz2qdkRhxPP4cVuUU8HIXdqdeHG0XpCVbdK4JX+ok2B1nmMLaxAE4Ll8o cogg==
MIME-Version: 1.0
Received: by 10.42.61.16 with SMTP id s16mr4770807ich.7.1344038227496; Fri, 03 Aug 2012 16:57:07 -0700 (PDT)
Received: by 10.50.34.169 with HTTP; Fri, 3 Aug 2012 16:57:07 -0700 (PDT)
Received: by 10.50.34.169 with HTTP; Fri, 3 Aug 2012 16:57:07 -0700 (PDT)
In-Reply-To: <501C3999.3080804@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>
Date: Fri, 03 Aug 2012 19:57:07 -0400
Message-ID: <CAG4d1rdo3BuEukb9F0aR=wOkKFEM9_esaJVJvn+e_UndQ3jELg@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>
Content-Type: multipart/alternative; boundary="20cf301cc2e21d4fbf04c6654988"
Cc: idr@ietf.org, Volker Hilt <volker.hilt@bell-labs.com>, 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: Fri, 03 Aug 2012 23:57:10 -0000
I strongly agree that we need to start collecting the use-cases for multiple abstraction levels as well as physical/virtual/private. Alia On Aug 3, 2012 4:51 PM, "Y. Richard Yang" <yry@cs.yale.edu> wrote: > 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<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-gredler-idr-ls-distribution-02> >>>> http://tools.ietf.org/html/**draft-ietf-alto-protocol-12<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<https://www.ietf.org/mailman/listinfo/irs-discuss> >>>>>>> >>>>>> ______________________________**_________________ >>>>>> irs-discuss mailing list >>>>>> irs-discuss@ietf.org >>>>>> https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss> >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>> irs-discuss mailing list >>>>> irs-discuss@ietf.org >>>>> https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss> >>>>> >>>>> ______________________________**_________________ >>>> irs-discuss mailing list >>>> irs-discuss@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss> >>>> >>> >>> ______________________________**_________________ >>> irs-discuss mailing list >>> irs-discuss@ietf.org >>> https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss> >>> >> ______________________________**_________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss> >
- [irs-discuss] Suggestions for IRS Way Forward James Kempf
- Re: [irs-discuss] Suggestions for IRS Way Forward Alia Atlas
- Re: [irs-discuss] Suggestions for IRS Way Forward Thomas Nadeau
- Re: [irs-discuss] Suggestions for IRS Way Forward Susan Hares
- Re: [irs-discuss] Suggestions for IRS Way Forward Robert Raszuk
- Re: [irs-discuss] Suggestions for IRS Way Forward Susan Hares
- Re: [irs-discuss] Suggestions for IRS Way Forward Thomas Nadeau
- Re: [irs-discuss] Suggestions for IRS Way Forward Robert Raszuk
- Re: [irs-discuss] Suggestions for IRS Way Forward Susan Hares
- Re: [irs-discuss] Suggestions for IRS Way Forward Susan Hares
- Re: [irs-discuss] Suggestions for IRS Way Forward Thomas Nadeau
- Re: [irs-discuss] Suggestions for IRS Way Forward James Kempf
- Re: [irs-discuss] Suggestions for IRS Way Forward Susan Hares
- Re: [irs-discuss] Suggestions for IRS Way Forward Jan Medved (jmedved)
- Re: [irs-discuss] Suggestions for IRS Way Forward Jan Medved (jmedved)
- [irs-discuss] About ALTO Vs. BGP-LS stefano previdi
- Re: [irs-discuss] About ALTO Vs. BGP-LS Y. Richard Yang
- Re: [irs-discuss] Suggestions for IRS Way Forward Susan Hares
- Re: [irs-discuss] Suggestions for IRS Way Forward Alia Atlas
- Re: [irs-discuss] Suggestions for IRS Way Forward Alia Atlas
- Re: [irs-discuss] About ALTO Vs. BGP-LS Susan Hares
- Re: [irs-discuss] About ALTO Vs. BGP-LS Y. Richard Yang
- Re: [irs-discuss] About ALTO Vs. BGP-LS Volker Hilt
- Re: [irs-discuss] About ALTO Vs. BGP-LS Y. Richard Yang
- Re: [irs-discuss] About ALTO Vs. BGP-LS Alia Atlas
- Re: [irs-discuss] [alto] About ALTO Vs. BGP-LS Greg Bernstein
- Re: [irs-discuss] [alto] About ALTO Vs. BGP-LS Greg Bernstein
- Re: [irs-discuss] About ALTO Vs. BGP-LS Hannes Gredler
- Re: [irs-discuss] About ALTO Vs. BGP-LS Volker Hilt
- Re: [irs-discuss] [alto] About ALTO, BGP-LS, IRS Greg Bernstein
- Re: [irs-discuss] [Idr] [alto] About ALTO, BGP-LS… Hannes Gredler
- Re: [irs-discuss] Suggestions for IRS Way Forward Susan Hares