[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