[irs-discuss] coments on draft-keyupate-irs-bgp-usecases-01
Seiichi Kawamura <kawamucho@mesh.ad.jp> Mon, 29 October 2012 05:15 UTC
Return-Path: <kawamucho@mesh.ad.jp>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E08921F86FB for <irs-discuss@ietfa.amsl.com>; Sun, 28 Oct 2012 22:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 lJ6uNsHt+kmB for <irs-discuss@ietfa.amsl.com>; Sun, 28 Oct 2012 22:15:05 -0700 (PDT)
Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by ietfa.amsl.com (Postfix) with ESMTP id 163DE21F85DF for <irs-discuss@ietf.org>; Sun, 28 Oct 2012 22:15:04 -0700 (PDT)
Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q9T5F3nT023990 for <irs-discuss@ietf.org>; Mon, 29 Oct 2012 14:15:03 +0900 (JST)
Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q9T5F3Z01176 for irs-discuss@ietf.org; Mon, 29 Oct 2012 14:15:03 +0900 (JST)
Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id q9T5F2rJ010227 for <irs-discuss@ietf.org>; Mon, 29 Oct 2012 14:15:02 +0900 (JST)
Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id q9T5F2t8009916 for <irs-discuss@ietf.org>; Mon, 29 Oct 2012 14:15:02 +0900
Received: from [127.0.0.1] (osknet452.sys.biglobe.nec.co.jp [10.84.99.49]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id q9T5F2Cl028371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <irs-discuss@ietf.org>; Mon, 29 Oct 2012 14:15:02 +0900
Message-ID: <508E10D1.9030706@mesh.ad.jp>
Date: Mon, 29 Oct 2012 14:14:57 +0900
From: Seiichi Kawamura <kawamucho@mesh.ad.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: irs-discuss@ietf.org
X-Enigmail-Version: 1.4.5
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig9A8E98BAC5C02CC29F9E90DC"
Subject: [irs-discuss] coments on draft-keyupate-irs-bgp-usecases-01
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2012 05:15:06 -0000
Hi Authors This is a great draft. Exactly what I want in my ISP network. I have a few comments and thoughts. Section2.2 o "Filter prefixes that are not allocated by Internet Routing Registries." IRRs do not allocate prefixes. Do you mean filter prefixes not registered on IRRs, or filter prefixes not allocated by IANA/RIR? I would go for the latter. o "This helps avoid prefix hijacking." I would say "This helps avoid prefix hijacking, including unintentional misconfiguration announcements." o JPIRR, run by JPNIC in coordination with the Japanes operator community has quite an accurate record because it requires authorization and yearly updates to the data. However, the complexity of the operation has not caught on with other IRRs. Miscellaneous o I didn't see a section in the document that described the situations for a newly configured BGP session. When you configure a new session, you may want to set BGP passive, especially if the neighbor requests MD5 because that would generate messy logs. When the peer does come up though, that passive needs to be deleted. All this could be done through IRS. After the BGP session comes up, and if the neighbor is advertising unexpected address families and timers IRS could send that information to the controller, and the controller could decide whether to shut it down or not. This will mitigate unwanted BGP session flapping. o Many ISPs use peeringdb.com to exchange peering info these days. Would an API to directly query peeringdb be helpful? I guess this is a question that would be nice to discuss among the operators and the people who maintain peeringdb. Regards, Seiichi
- [irs-discuss] coments on draft-keyupate-irs-bgp-u… Seiichi Kawamura