Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

Robert Raszuk <robert@raszuk.net> Sat, 11 June 2016 02:30 UTC

Return-Path: <rraszuk@gmail.com>
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 C0A1C12D871 for <idr@ietfa.amsl.com>; Fri, 10 Jun 2016 19:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF6n-OMGLXxG for <idr@ietfa.amsl.com>; Fri, 10 Jun 2016 19:30:15 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902AF12D5BE for <idr@ietf.org>; Fri, 10 Jun 2016 19:30:14 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id j7so32115137lfg.1 for <idr@ietf.org>; Fri, 10 Jun 2016 19:30:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6Y63KaZyiHR3A0WdUj0JHoesXhqAtY6hoCZwKzIpff8=; b=oCh1onuNZQk9+5axu8ACAk35c0uHpIon4tBg7UBOljDdYA2vjonGPjEFVUSYB6JNGO TQY9I8fjn2Z92CpYxOeVGKVJ1d+GLocaGkYhNhSeZt3nEJVB8i8jwx7S0UlFO3rYYxkr tuqgoCobjHfj5s4EZlZq2+RkLrbjwzCdv/K30kHOVucHBxBlZRRje//6rrbY/OyDbHp7 RnLH2lPAP4tpyJrd0lWgABYrTNEuSzafzLFvcJcQV6/ynfSQjITNh0uIR79d8gbkt+NV xkTCXxYslrGLlTUBRlGe6xs6bWelTwSh14dAQmrEfhDjE2yqNBgmRkgdHZwQkB39IuRn GcCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6Y63KaZyiHR3A0WdUj0JHoesXhqAtY6hoCZwKzIpff8=; b=CovzRPepNh+waAYfgGwj38DdlXxHEIMrW5oWJnw85QYgSah0hdMV/sxNCnS50k5jUz ZH/nRnoZDL19TRh3R3NZb+zNPgmgX1hMs3Y60kOW4IAfSUmMMNO7yhjpetHHADjpJGOi vQEPw3OcmCUaAjeSBdBu+g1UjVxRoxFVAK+y/Gb++2NnUn/AefFF11TtOKBnzyjUvhNb ZO/tdx4CQvBSJb+qCtDMndyftMT4EGqVTGTkp1P0qgtOCV8fZHArfzKxL8OE6rklkhht NvgKReVVFT13lYLq0pe5z5YLTiLcU0rqk7s1S1OdI+79GKvxZX5dC0C++qSrZE7UxlwC HCDw==
X-Gm-Message-State: ALyK8tIuz4T5JkYUzZ07IwBwMyJ/JKOQmjMuZd7Y05k4EXF5STiv8KwapauzYlhLLzZTcpJ4PTrGB0PJjGgEAQ==
X-Received: by 10.25.84.80 with SMTP id i77mr1448799lfb.88.1465612212530; Fri, 10 Jun 2016 19:30:12 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.25.21.30 with HTTP; Fri, 10 Jun 2016 19:30:11 -0700 (PDT)
In-Reply-To: <m2ziqsqy46.wl%randy@psg.com>
References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <CA+b+ERmCugH3kV5-yCG7=ArQGvzCeOV9Fij0=0-WqDU=YYa52A@mail.gmail.com> <CA+b+ER=fcFXVdLN475QeE=5-DfdhmVd0LxBMzo4MogGcjTaYxQ@mail.gmail.com> <CA+b+ERk_-8P0YsCC1cFEscLBMG37oaNLvXnqRABZ2kt+yuyTsw@mail.gmail.com> <CAHgCvCPFE9zAu3g_RMvM3PnmC1oBEECq6Q7n0V8Td-qhY51Yow@mail.gmail.com> <CA+b+ER=3z=wPm6dy4+OeBrp7a-+=syy1ZX_DESXfe77P1Cbumw@mail.gmail.com> <m2ziqsqy46.wl%randy@psg.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 11 Jun 2016 04:30:11 +0200
X-Google-Sender-Auth: SXoMreH4o_B60NbaAmYoKzrsiio
Message-ID: <CA+b+ERnD1kHPZ_mvSeb66TJW=XT6h9UDWfpphnJfob5yKQV03Q@mail.gmail.com>
To: Randy Bush <randy@psg.com>
Content-Type: multipart/alternative; boundary=001a11405a284e75980534f76f05
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/vAu-vyVcduW4Q2B7WcDpvFuKWUw>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 11 Jun 2016 02:30:17 -0000

I must admit that you are right to say that true skill is in finding some
way to help address the problem for vast majority of deployments.

I also agree that while best protocol design skills are in addressing
corner cases here no loop will form and no harm to routing would be done if
say 5% disable that capability.

However my honest observation is that this approach would work well when
operators would only operate on binary BGP code with such functionality
enabled as mandatory capability and be always ON by default with no option
to disable it.   Said this we all have to admit that such times are long
gone and as soon as NOC have a business case and chance to disable it their
marketing folks will force them to do so.

So the real question comes to the point if IDR is in position to issue RFCs
to test ISP marketing guys in their level of power to enforce big vendors
to add knobs disabling such capabilities or speeding up shifting to open
source BGP ....

Tx,
r.



On Sat, Jun 11, 2016 at 4:04 AM, Randy Bush <randy@psg.com>; wrote:

> >> In spite of your concerns RS is a perfect place to deploy roles: RS does
> >> not provide IP-transit (if there are no leaks!) but it *provides* local
> >> connectivity. So, RS is provider for all its neighbors.
> > You mean other then FT's OpenTransit ?
>
> welcome to the kinky internet, where every thinkable and unthinkable act
> is done; after all, it was invented in california. :)
>
> if you are planning something kinky, do not bring a straight friend to
> the party.  that is, as i said to job, if you intend to violate valley
> free or peer-peer, do not run mechanisms designed to detect these as
> errors.
>
> perhaps we should design for the norm.  with things this complex, we can
> always find corner cases.  though i guess one can make a career out of
> finding them; it's a target rich environment.  true skill is in finding
> the simple middle path.
>
> randy
>