IETF Logo Mail Archive

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

Russ White <russw@riw.us> Tue, 11 December 2012 18:26 UTC

Return-Path: <russw@riw.us>
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 0F57821F8812 for <idr@ietfa.amsl.com>; Tue, 11 Dec 2012 10:26:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.603
X-Spam-Level:
X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396]
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 SJV+CgWAQMpR for <idr@ietfa.amsl.com>; Tue, 11 Dec 2012 10:26:06 -0800 (PST)
Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5003F21F8802 for <idr@ietf.org>; Tue, 11 Dec 2012 10:26:04 -0800 (PST)
Received: from nat1.corp-fo.iad1.verisign.com ([216.168.230.7] helo=[10.88.68.144]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from <russw@riw.us>) id 1TiUWp-0007iS-C2; Tue, 11 Dec 2012 10:26:03 -0800
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>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CA+b+ERnSVvewSpftXs3FhW12-S+sgnB1SwD4L+xqFW+hhbQayw@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <7120600D-71BD-4E61-8F06-25B7C2BAE6A8@riw.us>
X-Mailer: iPad Mail (10A523)
From: Russ White <russw@riw.us>
Date: Tue, 11 Dec 2012 13:26:03 -0500
To: Robert Raszuk <robert@raszuk.net>
X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner
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: Tue, 11 Dec 2012 18:26:07 -0000

+1

Lets steer away from the justifications in a draft, as they might well change over the next 5 years anyway. The justification seems well supported o list, so make the draft simple...

:-)

Russ

<><
russw@riw.us
riwhite@verisign.com

On Dec 11, 2012, at 11:54 AM, Robert Raszuk <robert@raszuk.net> wrote:

> All,
> 
> 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.
> 
> I think Jon in fact already said it very clearly that the point of the
> draft is to get IANA registration. That' it - no more no less.
> 
> It would be up to individual operators to use such new range in L3VPNs
> as Shane points out, in DCs or for that matter in ISPs.
> 
> Also it seems that it could be useful for dynamically routed home
> gateways and in that respect I think the current range may be in fact
> too small so I am sympathetic to broaden this space. If this is bit
> boundary aligned or human aligned I think is secondary .. I have no
> personal preference.
> 
> Many thx,
> R.
> 
> 
> 
> On Tue, Dec 11, 2012 at 12:37 AM, Randy Bush <randy@psg.com> wrote:
>> this misses my point entirely.  we know not to announce private ASs.
>> 
>> my point was
>> 
>>  o i do not accept the use example in the draft as justification
>>    for an allocation of more private ASs.  in fact, i object to
>>    it and specifically object to the draft being advanced.  we do
>>    this already without your requested allocation which then can
>>    only be viewed as an end-run around the IR system.
>> 
>>  o i can see tli's point about use in large datacenter deployments.
>>    if the draft is changed to use that (or a similar real need) as
>>    the motivation, i would reconsider my objection.
>> 
>> apologies, but i do not know how to be more clear.
>> 
>> randy
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

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