IETF Logo Mail Archive

Re: [Idr] [GROW] draft-mauch-bgp-reject

Robert Raszuk <robert@raszuk.net> Thu, 05 November 2015 09:38 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADD71A905E; Thu, 5 Nov 2015 01:38:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 z1zlkKtOIDfC; Thu, 5 Nov 2015 01:38:41 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 4BA011A905B; Thu, 5 Nov 2015 01:38:41 -0800 (PST)
Received: by wmll128 with SMTP id l128so8104307wml.0; Thu, 05 Nov 2015 01:38:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZvBwFa6Ti4jGwoCwQZJYdctRgLDJxHjcq05RwFO119Q=; b=LSSq6oebaSgD9ZQZpLF32Yc1NY/ggk+h9XM4+8355GT2tQ8CZFdQW2JP/MAFu4ida+ rbitqWqOn+vbNd3uNfigKTLsvkFyaJ1/kHn/U1wxM9rldJ/PblTdT2aSKy+yH9y20WN5 0X8TgZhCN+YvWTUxH5S1qQyvPm8i9fmu9MMJbhWfq6XhazZVVw/9VBPdi5gjSRl0A5dU ki0PvCX24vvOr3+G8gwG/4dgM0FuMWdDeuh/qesK/CGN47xwNo3OkAooz4R/UW7vuMeD peDp8Lenlz9ORMICINTWSDQuIkkt2LP3iWzALbbXhXt0I4vvDGp1uTIlIeSthWyRrlBT crmw==
MIME-Version: 1.0
X-Received: by 10.28.138.148 with SMTP id m142mr2427180wmd.2.1446716319838; Thu, 05 Nov 2015 01:38:39 -0800 (PST)
Sender: rraszuk@gmail.com
Received: by 10.194.204.195 with HTTP; Thu, 5 Nov 2015 01:38:39 -0800 (PST)
In-Reply-To: <B1CF5B9F-7827-4A2D-9DAD-0D5C50C5F393@puck.nether.net>
References: <E1A51A62-A164-4F9C-AE67-CC8F3C3AB85D@puck.nether.net> <20151102093733.GF70452@Space.Net> <B1CF5B9F-7827-4A2D-9DAD-0D5C50C5F393@puck.nether.net>
Date: Thu, 05 Nov 2015 18:38:39 +0900
X-Google-Sender-Auth: 7n8FQxqiMOZU4Ep4W2BkO26WU7o
Message-ID: <CA+b+ERkBPDawAiw+uFZgOYwQVLkHUGVXXqwe7BfF60ajwWuSug@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Jared Mauch <jared@puck.nether.net>
Content-Type: multipart/alternative; boundary="001a1144275a55b8320523c7e40f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/hyBG8zRVYALzYPTEvl1Io0hbVZ8>
Cc: idr wg list <idr@ietf.org>, "grow@ietf.org" <GROW@ietf.org>, Gert Doering <gert@space.net>
Subject: Re: [Idr] [GROW] draft-mauch-bgp-reject
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Nov 2015 09:38:43 -0000

Hi Jared,

​If you are up to fail-open on restart (I guess this is what you mean by
"internal-failures") and in fact in general regarding your entire draft IMO
the only way to really enforce anything of that scope is to update 4271
with the new eBGP rules and state machine.

Otherwise I do not believe that BCP will  be out of the sudden honored by
vendors. Also I do not think it will be justified to be accept globally as
an OS upgrade without such strong enforcement.

Thx,
r.



> > There is one item I don't understand here:
> >
> >   o  Software MUST provide protection from internal failures preventing
> >      the advertisement and acceptance of routes
> >
> > what does that mean (in other words "more verbose explanation, please")?
>
> Vendor software will actually fail-open and not honor the configured
> policy.  I’d like to try and capture this case as implementation guidance
> to prevent damage to the global internet.
>
> - Jared
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

v2.23.0 | Report a Bug | By Email