Re: [Idr] Alissa Cooper's No Objection on draft-ietf-idr-as-migration-03: (with COMMENT)

Randy Bush <> Thu, 19 February 2015 22:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 98A9E1A001B; Thu, 19 Feb 2015 14:42:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qVS9_gpfMCIZ; Thu, 19 Feb 2015 14:42:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F8761A0007; Thu, 19 Feb 2015 14:42:04 -0800 (PST)
Received: from localhost ([] by with esmtp (Exim 4.82) (envelope-from <>) id 1YOZnE-0006ry-JC; Thu, 19 Feb 2015 22:42:01 +0000
Date: Fri, 20 Feb 2015 07:41:58 +0900
Message-ID: <>
From: Randy Bush <>
To: Wes George <>
In-Reply-To: <>
References: <> <022301d04bc5$1ca2b490$55e81db0$> <> <02c001d04bda$ed0eaca0$c72c05e0$> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <>
Cc: Chris Morrow <>, idr wg <>, Alissa Cooper <>, IESG <>
Subject: Re: [Idr] Alissa Cooper's No Objection on draft-ietf-idr-as-migration-03: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Feb 2015 22:42:05 -0000

>> This document is written by two operators, documenting the operational
>> issue that makes this functionality important which in turn drove them
>> to write the document. Therefore I do think that it's important to
>> draw the connection between As-Path lengthening and revenue loss, as
>> this is the business reality.
> i am an operator.  i do not support this statement.

after my first cuppa, allow me to expand.

when this doc first came out, i asked, with negligible success, it be
put on a radical diet.  so i thought what the heck, i have bigger fish
to fry.  same for it's mate over in sidr, which is the one about which i
care more.  but it seems the iesg has reached a similar conclusion.  so
let me try to suggest how.

we all agree the hack needs to be documented, you do not need to sell or
otherwise motivate it.  to accomplish x you need to do y.  fertig.

so get all the non technical stuff out.  and i mean all.  if you need to
save the immortal prose, publish it as a ripe series ops doc (and if you
say bcop i will puke).

try a gedanken experiment of seeing how little you can say to convey the
hack to the vendor and the op who has to configure it.  i bet you can
get it down to 3-4 pages excluding ietf boilerplate.  think of it like
code, the more of it there is the more room for bugs.

college years our roomies were at iit architecture, the mies school.
less is more.