Subject: [irs-discuss] coments on draft-keyupate-irs-bgp-usecases-01

From: Seiichi Kawamura <[email-masked]>
Date: Mon, 29 Oct 2012 14:14:57 +0900

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