Re: [rrg] procedural aggregation

William Herrin <bill@herrin.us> Sun, 09 March 2014 02:56 UTC

Return-Path: <wherrin@gmail.com>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0B11A0301 for <rrg@ietfa.amsl.com>; Sat, 8 Mar 2014 18:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.621
X-Spam-Level:
X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1-96isd2oiS for <rrg@ietfa.amsl.com>; Sat, 8 Mar 2014 18:56:49 -0800 (PST)
Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0678D1A02F6 for <rrg@irtf.org>; Sat, 8 Mar 2014 18:56:48 -0800 (PST)
Received: by mail-ve0-f172.google.com with SMTP id jx11so5751448veb.17 for <rrg@irtf.org>; Sat, 08 Mar 2014 18:56:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=OSUa/NZPFo2dvTFLeWs7LJx2fhwCT5w7osJnPUC6piQ=; b=sP9N2kOYMt/61yOGzxnvckaV0tYhggt1vm/it40ydSrVcWUYF8GUXV2H/Tu2h+KBgP EcSw8yOnZORrgAIB9ISgo4/BuaSmrwHDrPNc68UkSCLgraQaqSkj18tO40/H8kB0+NQT 0GfhsEGAVyCHFXNXSgkR3sm4Y7MuSrJx3c17fr+sYjeA4gMb2ebWyQhx8hnoR29qE0wJ FNL8NeaJ4VRzzGEAxPxmbpiB1CV5a/QPYCYg2F1ebuOym3KRvBHS/Eef9fWOzeoV/BsC ODPB6IoUBD0Ldy1eH+z6usOQYh2sVaAOWrSdNAL48XYlsQKn6GUkA93/pZLuqTPgxHY3 oDUw==
X-Received: by 10.52.61.133 with SMTP id p5mr17659966vdr.4.1394333803956; Sat, 08 Mar 2014 18:56:43 -0800 (PST)
MIME-Version: 1.0
Sender: wherrin@gmail.com
Received: by 10.52.38.234 with HTTP; Sat, 8 Mar 2014 18:56:23 -0800 (PST)
In-Reply-To: <53176AF6.1040308@joelhalpern.com>
References: <CAP-guGXyxehmCiskATSLOouE0Cx1i9KFroK60r=xWe-Lu7peSA@mail.gmail.com> <8D106691E2F8808-2798-932B@webmail-d162.sysops.aol.com> <CAP-guGU4QCHSOnr99hhvksNa8=zm_OZ9bR34HhHv7WCK55sVvw@mail.gmail.com> <5317511D.20506@joelhalpern.com> <CAP-guGVEXDe=YBgGd4Y_kSTsoRH+osfNvqmd+9KwB5pY3C6x-g@mail.gmail.com> <53176AF6.1040308@joelhalpern.com>
From: William Herrin <bill@herrin.us>
Date: Sat, 8 Mar 2014 21:56:23 -0500
X-Google-Sender-Auth: yKjA7VbYAGJNM_C-IqlhQdRt_8k
Message-ID: <CAP-guGUerSYu+Xy4FJ+3EUTn-j45CAF0hSU=cpR61XeKZW9gvg@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/rrg/PJpheWOnhU1fKDJ40Y_ewm5UW84
Cc: RRG <rrg@irtf.org>
Subject: Re: [rrg] procedural aggregation
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg/>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Mar 2014 02:56:51 -0000

On Wed, Mar 5, 2014 at 1:20 PM, Joel M. Halpern <jmh@joelhalpern.com>; wrote:
> 1) The set of traffic allowed is more nuanced and varied than just the two
> categories of transit and peer.

Howdy,

Following up on a private suggestion from Joel, I polled network
operators and identified either a modification to the definition of
transit or a third kind of interaction between ASes depending on how
you want to look at it. For now I'll treat it as a third kind call
these REN links after the Research and Education Networks where they
most commonly appear.

REN links happen when several networks share a tightly bound market
niche, such as schools in a particular region. Networks serving this
niche agree to peer to take data off of their paid transit
connections. Then they take the extra and mutual step of permitting
each neighbor who serves the niche to transit their internal backbones
to each other neighbor serving the same niche. This creates a sort of
shadow network improving the customers' access to each other.

This seems to serve as an entry fee to gain access to the market niche
-- customers are disinclined to choose a service provider who does not
participate. It may also be a mechanism for protecting these typically
smaller service providers from competition by large multinational
networks who would find it challenging to participate due to the size
and complexity of their networks.


A number of other examples were put forward but in my opinion they
were straightforward variants of the transit service I've already
defined. For example, one individual claimed HE's IPv6 tunnels were a
valley because they're free and not limited to peering. However, HE's
tunnel service is clearly simple transit under the definition in my
earlier post.


With that, can anyone offer an additional concrete example of a
relationship between two neighboring ASes besides transit, peering and
REN links? Or have we pretty much captured it?

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin@dirtside.com  bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004