Re: [irs-discuss] About ALTO Vs. BGP-LS
"Y. Richard Yang" <yry@cs.yale.edu> Fri, 03 August 2012 18:46 UTC
Return-Path: <yry@cs.yale.edu>
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 92B2F21F8E3C; Fri, 3 Aug 2012 11:46:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
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 j6zV8hZmuJQ0; Fri, 3 Aug 2012 11:46:23 -0700 (PDT)
Received: from vm-emlprdomr-02.its.yale.edu (vm-emlprdomr-02.its.yale.edu [130.132.50.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0F14921F8E3A; Fri, 3 Aug 2012 11:46:22 -0700 (PDT)
Received: from Faculty-Supports-MacBook-Pro-2.local ([128.36.46.193]) (authenticated bits=0) by vm-emlprdomr-02.its.yale.edu (8.14.4/8.14.4) with ESMTP id q73IkDeo016975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Aug 2012 14:46:13 -0400
Message-ID: <501C1C74.6040006@cs.yale.edu>
Date: Fri, 03 Aug 2012 11:46:12 -0700
From: "Y. Richard Yang" <yry@cs.yale.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Susan Hares <susan.hares@huawei.com>, idr@ietf.org
References: <CC404D94.2D5D%tnadeau@juniper.net> <501B0D75.4090009@raszuk.net> <7E89A05A-CE4E-4FCF-81AB-8F39B42FBF8E@cisco.com> <501C128D.10809@cs.yale.edu> <728F9B956B2C48439CA9294B1723B14623756237@dfweml509-mbs.china.huawei.com>
In-Reply-To: <728F9B956B2C48439CA9294B1723B14623756237@dfweml509-mbs.china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.71 on 130.132.50.143
Cc: "robert@raszuk.net" <robert@raszuk.net>, "irs-discuss@ietf.org" <irs-discuss@ietf.org>, James Kempf <james.kempf@ericsson.com>, IETF ALTO <alto@ietf.org>, Thomas Nadeau <tnadeau@juniper.net>, "Y. Richard Yang" <yry@cs.yale.edu>, 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 18:46:24 -0000
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 idr@ietf.org 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: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Y. Richard Yang > Sent: Friday, August 03, 2012 11:04 AM > To: stefano previdi > Cc: Thomas Nadeau; James Kempf; IETF ALTO; robert@raszuk.net; irs-discuss@ietf.org > 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" <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
- [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