IETF Logo Mail Archive

Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

"Susan Hares" <shares@ndzh.com> Fri, 21 December 2012 00:01 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8894F21F8A70 for <idr@ietfa.amsl.com>; Thu, 20 Dec 2012 16:01:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.267
X-Spam-Level: *
X-Spam-Status: No, score=1.267 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kyTp3yNDBSU for <idr@ietfa.amsl.com>; Thu, 20 Dec 2012 16:01:50 -0800 (PST)
Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9933321F8A6B for <idr@ietf.org>; Thu, 20 Dec 2012 16:01:49 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202;
From: Susan Hares <shares@ndzh.com>
To: 'Edward Crabbe' <edc@google.com>, 'Nick Hilliard' <nick@foobar.org>
References: <1AC79BDA-C088-47B4-888D-4B0428FB7C4F@puck.nether.net> <B549F708-0D5E-4B22-AC91-B6CE61B258FE@tony.li> <CAL9jLaZdX_jem0JdSGHzuhc3GDZXMDR0kvMKq5xr3D-EWYbNVQ@mail.gmail.com> <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <m2bodoodtx.wl%randy@psg.com> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <50D3991B.2040809@foobar.org> <CACKN6JEOTmUHH_0+x_tSfgruW=VhCtKknmyVAVCkviWM+WVZ+A@mail.gmail.com>
In-Reply-To: <CACKN6JEOTmUHH_0+x_tSfgruW=VhCtKknmyVAVCkviWM+WVZ+A@mail.gmail.com>
Date: Thu, 20 Dec 2012 19:01:29 -0500
Message-ID: <028a01cddf0e$55168d90$ff43a8b0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_028B_01CDDEE4.6C4392D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQF9v/6ArthbJCXvPOQlollKSNupRwJmxqN6Ae2IgloCr9hVXgEa8bQpAbE5dxQCO7v+TgI2uifkAwjVA9cBmIxC9QJWdUb9Ai04lyEBLBVY65f9+zxQ
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Cc: 'idr wg' <idr@ietf.org>
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Dec 2012 00:01:51 -0000

Edward:

 

+1 - that Certainly Acquisitions and ASN mergers will cause multiple private
ASNs. 

 

The draft's text says :

 

" Private Use ASNs must be removed from the AS_Path before being advertised
to the global Internet."  

 

The question is not whether it goes out of a single Private ASN, but whether
it cross the global Internet.  For example, if several private DCs band
together to have a private exchange beyond the reaches of the global
Internet, I have no reason to specify what happens with private ASN behind
in those private party exchanges. 

 

How do certain Acquisition and ASN mergers cause private ASN to cross the
global Internet?  And why are these private AS not being hidden by a public
AS or AS Confederation. 

 

Sue 

 

From: Edward Crabbe [mailto:edc@google.com] 
Sent: Thursday, December 20, 2012 6:34 PM
To: Nick Hilliard
Cc: Jon Mitchell; idr wg; Susan Hares
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

 

+1

 

Acquisitions, ASN merges etc may all involve use of private ASN space
between consenting parties.  I think this is a SHOULD.  

 

On Thu, Dec 20, 2012 at 3:02 PM, Nick Hilliard <nick@foobar.org> wrote:

On 20/12/2012 22:38, Jon Mitchell wrote:
> I'm comfortable making the change to a capital MUST for this sentence
> and adding the appropriate reference to RFC 2119 as necessary.  I'm just
> not comfortable telling operators how to perform that action as there
> are a number of options to do so, which was my point to David (and he
> seemed to be ok with).  I will make the changes as necessary to the
> abstract where this statement exists as well.

If it's of interest, rfc 6666 ran into much the same issue recently with
the issue of leaking the rtbh prefix to ebgp peers.  We decided on SHOULD
rather than MUST because there probably were situations where there might
be valid operational reasons for leaking the prefix to a peer. I would
think the same arguments hold for a private ASN range.

http://tools.ietf.org/html/rfc6666#section-5

Nick


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

v2.31.3 | Report a Bug | By Email | System Status