Re: [rrg] More abbreviation expansions

Ruediger Volk <rv@NIC.DTAG.DE> Sun, 28 February 2010 21:37 UTC

Return-Path: <rv@kronos.NIC.DTAG.DE>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A80828C1B1 for <rrg@core3.amsl.com>; Sun, 28 Feb 2010 13:37:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.801
X-Spam-Level:
X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec1oPlfVMjw4 for <rrg@core3.amsl.com>; Sun, 28 Feb 2010 13:37:16 -0800 (PST)
Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by core3.amsl.com (Postfix) with ESMTP id B215028C161 for <rrg@irtf.org>; Sun, 28 Feb 2010 13:37:15 -0800 (PST)
Received: from kronos.NIC.DTAG.DE (kronos.NIC.DTAG.DE [194.25.1.92]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id WAA25532; Sun, 28 Feb 2010 22:37:11 +0100 (MET)
Received: from x37.NIC.DTAG.DE (x37.NIC.DTAG.DE [194.25.1.186]) by kronos.NIC.DTAG.DE (8.8.5/8.7.1) with ESMTP id WAA12930; Sun, 28 Feb 2010 22:37:12 +0100 (MET)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
From: Ruediger Volk <rv@NIC.DTAG.DE>
In-Reply-To: Your message of "Sun, 28 Feb 2010 13:33:59 +1300." <4B89B9F7.2010707@gmail.com>
Date: Sun, 28 Feb 2010 22:37:12 +0100
Message-ID: <27.1267393032@x37.NIC.DTAG.DE>
Sender: rv@kronos.NIC.DTAG.DE
Cc: Tony Li <tli@cisco.com>, RRG <rrg@irtf.org>
Subject: Re: [rrg] More abbreviation expansions
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/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, 28 Feb 2010 21:37:17 -0000

  > I have always understood PA to mean Provider Aggregatable
  > or Provider Aggregated (which is of course only possible
  > because they are assigned by the provider who will perform
  > the aggregation).
  > 
  > In terms of history, I have in my archive a note drafted
  > in 1995 by Daniel Karrenberg at RIPE, entitled
  > "Provider Independent vs Provider Aggregatable Address Space"
  > (sent to nanog@merit.edu, cidrd@iepg.org, IANA@isi.edu and
  > local-ir@ripe.net on 17 May 1995).
  > 
  > "provider assign[ed]" also pops up in my archive from the same
  > era, but "aggregatable" seems to be the more common usage
  > (46 vs 18 hits in my archive).
I'm also used to expand the "A" to "Aggregatable" (thanks for the supporting
stats:-)

I'd prefer sticking with that interpretation:
- "aggregation" seems to be much more the core concept that is of interest
  while "assigned" seems more coincidental
- also note that it happens all the time that by (change of) policy
  provider assigned address space is turned into PI - unfortunately :-(

It does not look like a good idea to dilute the "routing semantics" of PA
this way and creating the need for another term that precisely captures
the ability to aggregrate.

  > Regards
  >    Brian Carpenter
  > 
  > On 2010-02-27 14:41, Tony Li wrote:
  > > Hi all,
  > > 
  > > I've received the following proposed text:
  > > 
  > > PA - Provider Assigned: Addresses which cannot be 'taken with you' when a
  > > site moves to a different location on the network connectivity
  > > structure; usually assigned by a service provider (hence the name).
s/\(.*\)//
add (or something similar):
Global routing of a PA block usually can be supported by a route for just
the aggregate prefix (hence the name).

  > > PI - Provider Independent: Addresses associated with a site and which mov
e
> with it when it moves to a different location on the network connectivity
  > > structure; independent of any service provider (hence the name).
  > > 
  > > Any objections?
  > > 
  > > Tony
  > > 
  > > _______________________________________________
  > > rrg mailing list
  > > rrg@irtf.org
  > > http://www.irtf.org/mailman/listinfo/rrg
  > > 
  > _______________________________________________
  > rrg mailing list
  > rrg@irtf.org
  > http://www.irtf.org/mailman/listinfo/rrg

Ruediger Volk