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

Hannes Gredler <hannes@juniper.net> Mon, 06 August 2012 18:39 UTC

Return-Path: <hannes@juniper.net>
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 E042421E8089; Mon, 6 Aug 2012 11:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.431
X-Spam-Level:
X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 u8VQcwUaqiFt; Mon, 6 Aug 2012 11:39:38 -0700 (PDT)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3F321E8084; Mon, 6 Aug 2012 11:39:28 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUCAPXNE182p+6dL32dx0iHDNKt2VZSPR@postini.com; Mon, 06 Aug 2012 11:39:38 PDT
Received: from ubuntu (172.23.6.234) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 6 Aug 2012 11:38:56 -0700
Received: by ubuntu (Postfix, from userid 1000) id 1E44B2B300; Mon, 6 Aug 2012 20:39:11 +0200 (CEST)
Date: Mon, 6 Aug 2012 20:39:11 +0200
From: Hannes Gredler <hannes@juniper.net>
To: "Y. Richard Yang" <yry@cs.yale.edu>
Message-ID: <20120806183910.GC16802@juniper.net>
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> <501C1C74.6040006@cs.yale.edu> <728F9B956B2C48439CA9294B1723B146237562DC@dfweml509-mbs.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <728F9B956B2C48439CA9294B1723B146237562DC@dfweml509-mbs.china.huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "idr@ietf.org" <idr@ietf.org>, James Kempf <james.kempf@ericsson.com>, Susan Hares <susan.hares@huawei.com>, "robert@raszuk.net" <robert@raszuk.net>, irs-discuss@ietf.org
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: Mon, 06 Aug 2012 18:39:39 -0000

richard,

[ ... ]
| > 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.

one of the base ideas of BGP-LS has been to present a topology in a protocol
neutral form. As such it nicely solves the case where more than one
IGP (OSPF at the edge, IS-IS in the core) has been deployed.
It per does not flood IGP LSAs (including age), but rather the
normalized content of those LSAs - i find age information for the
topology less interesting as age it is purely for garbage collection.

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

wether BGP is a "routing-protocol" per se or not is mildly ;-) controversial
debate which we certainly cannot get full agreement by all list participants -
so let me present my view on that:

the way i see BGP is more as a multipoint (reflectors !) IPC facility where i can publish
state for the "universe". to my knowledge there are is no alternative protocol
that allows me to distribute state over a generic p2mp distribution graph.
so the reason BGP is so attractive as a generic state distribution mechanism
is because "its there" and it "works" and it has been abused exacatly
because of that by others in the past :-)

/hannes