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

Jon Mitchell <jrmitche@puck.nether.net> Wed, 12 December 2012 22:46 UTC

Return-Path: <jrmitche@puck.nether.net>
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 2C6F01F0CB9 for <idr@ietfa.amsl.com>; Wed, 12 Dec 2012 14:46:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Level:
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 1I9KG+t6cQ6B for <idr@ietfa.amsl.com>; Wed, 12 Dec 2012 14:46:44 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 056CE1F0409 for <idr@ietf.org>; Wed, 12 Dec 2012 14:46:43 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBCMkh14031044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 17:46:43 -0500
Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBCMkgkM031043; Wed, 12 Dec 2012 17:46:42 -0500
Date: Wed, 12 Dec 2012 17:46:42 -0500
From: Jon Mitchell <jrmitche@puck.nether.net>
To: Warren Kumari <warren@kumari.net>
Message-ID: <20121212224642.GA29400@puck.nether.net>
References: <CA+b+ERnuWZ+r2O-eFhe3hU00uoU4UKnRcbhLNVXU7p5+DjoWbQ@mail.gmail.com> <C6C16AE3B7961044B04A1BCEC6E2F93603D12A0C@xmb-rcd-x14.cisco.com> <20121210225858.GC24937@puck.nether.net> <m2d2yh32cw.wl%randy@psg.com> <CA+b+ERnSVvewSpftXs3FhW12-S+sgnB1SwD4L+xqFW+hhbQayw@mail.gmail.com> <m2ip871q5r.wl%randy@psg.com> <9ABE0240-8468-4884-ABDE-4A884D21F5DB@tony.li> <06401C9C-8895-4BDA-8FE3-6B06DF55D2A2@kumari.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <06401C9C-8895-4BDA-8FE3-6B06DF55D2A2@kumari.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 12 Dec 2012 17:46:43 -0500 (EST)
Cc: idr wg <idr@ietf.org>, Tony Li <tony.li@tony.li>, Robert Raszuk <robert@raszuk.net>
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: Wed, 12 Dec 2012 22:46:45 -0000

To those asking for justification -

RFC1930 is not replaced by this draft, only updated.  This draft adds
the following as justification for the 2nd range:

   The limited size of the current range of private use ASNs has led to
   the re-use of private use ASNs within a single organization,
   requiring the use of a number of implementation specific features
   that manipulate the AS_PATH or remove AS_PATH based loop prevention
   described in Section 9 of [RFC4271].  These workarounds have
   increased the operational complexity of the networks since the
   implementations of these functions vary and are not defined in
   existing BGP standards.
   
   < another paragraph justifies that the total amount of space is larger,
and asns are not a scarce resource >

If the first paragraph of the draft, by mentioning how BGP use has
increased in a number of networks confuses folks into thinking they are
justifying private ASNs for a specific use case, I've already said I'm
happy to make minor edits.

Since private ASNs are (w/o collectable data a total swag) deployed on
several orders of magnitude higher numbers of devices than public ASNs
and are used in many different ways, it seems to me focusing on any
particular use case is a bit silly and short sighted give the
justification above handles all use cases for the 2nd range and just
creates fodder for those who want to debate the usefulness from an
academic standpoint often while deploying the existing range in segments
of their own networks.

Even if we were to delineate a wide number of use cases for private asns
in DCs, large Enterprise private networks, labs, etc... (which I don't
think we have very good representation in IETF to fully expound upon),
do we think that somehow this would bound folks or somehow fix any
Internet leaking of the existing or new ranges? 

Jon


On Wed, Dec 12, 2012 at 11:34:18AM -0500, Warren Kumari wrote:
> 
> On Dec 12, 2012, at 11:07 AM, Tony Li <tony.li@tony.li> wrote:
> 
> > 
> > On Dec 12, 2012, at 3:11 AM, Randy Bush <randy@psg.com> wrote:
> > 
> >>> I think Jon should remove any use case examples from the draft as
> >>> there is no way one could enforce that the new range will _only_ be
> >>> used in those use cases.
> >> 
> >> if there is no documented motivation for it, then we don't need the
> >> draft at all.  simplifies live greatly.  great idea.  ;~>
> > 
> > 
> > Then we lard up every draft with marketing material.  Is that better?
> 
> Nope, no-one is suggesting marketing material -- but I think having *some* mention of a use case / justification is needed to readers can evaluate if the idea is worth the time / risk.
> 
> Providing instructions on how to build a little wooden platform with strong spring held back by a bent piece of metal that you can attach bits of curdled dairy makes no sense unless you explain that this will help solve their mouse problem...
> 
> W
> > 
> > Tony
> > 
> > 
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> > 
> 
> -- 
> Eagles soar but a weasel will never get sucked into a jet engine 
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr