IETF Logo Mail Archive

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

Jon Mitchell <jrmitche@puck.nether.net> Fri, 21 December 2012 00:21 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 3A4BA21F8A6B for <idr@ietfa.amsl.com>; Thu, 20 Dec 2012 16:21:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 f2fTkravcjiZ for <idr@ietfa.amsl.com>; Thu, 20 Dec 2012 16:21:06 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 37B3321F87B1 for <idr@ietf.org>; Thu, 20 Dec 2012 16:21:06 -0800 (PST)
Received: from [192.168.1.7] (pool-98-118-242-200.clppva.fios.verizon.net [98.118.242.200]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBL0KrHo006307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 19:20:54 -0500
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> <027701cddf09$1d074d90$5715e8b0$@ndzh.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <027701cddf09$1d074d90$5715e8b0$@ndzh.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <5A90C164-8E47-4A56-986F-634A1217E55E@puck.nether.net>
X-Mailer: iPhone Mail (10A523)
From: Jon Mitchell <jrmitche@puck.nether.net>
Date: Thu, 20 Dec 2012 19:20:52 -0500
To: Susan Hares <shares@ndzh.com>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 20 Dec 2012 19:20:54 -0500 (EST)
Cc: "<idr@ietf.org>" <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:21:08 -0000

I agree that any use case that requires the text to move to should is probably not a Private Use case by definition.

-Jon

On Dec 20, 2012, at 6:24 PM, "Susan Hares" <shares@ndzh.com> wrote:

> Nick:
> 
> I'd be interested in you suggesting the situations would be valid to leak
> the AS private path AS to a peer, before we downgrade to a "SHOULD". 
> 
> Sue 
> 
> -----Original Message-----
> From: Nick Hilliard [mailto:nick@foobar.org] 
> Sent: Thursday, December 20, 2012 6:03 PM
> To: Jon Mitchell
> Cc: Susan Hares; 'Randy Bush'; idr@ietf.org; stbryant@cisco.com
> Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00
> 
> 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
>

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