Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

Robert Raszuk <robert@raszuk.net> Wed, 19 April 2017 22:26 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 0B626129BCE for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 15:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 LufryWGVVcg6 for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 15:26:02 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 0F57E127A97 for <idr@ietf.org>; Wed, 19 Apr 2017 15:26:02 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id k87so40486315ioi.0 for <idr@ietf.org>; Wed, 19 Apr 2017 15:26:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DMOxUZBxLgCDlsKrpJNHZ9FxZ68QqN09PcLcDEQAZqg=; b=ouDYs2PF10HKHs02eEDipSS21KhDkINRLoaz7AgxtdwdzZSRI3EpowFSC21J9dODq+ EXFEfvpB2ZpT5DmCcG1C1i8+sbHWO8rRzsrtoRrJ02lXUj5c1NTTAkFGzqluj/rnlHKF EP9NnHGT85SSmGU8M4UEX75Bc/CCUWaDdNdHmFYNNs6buQ8odn5Ji/8N8e7dxjocSu7c l8ttlM6gG+CrX/wBnC93X1Q0SjCC04yLJQLRh+Lv7Iy9OCDfEDyePy/zlj+0RcMcOdUM SUbHNAeIDAMkLsWhCI51Gcgc9Js0eI5UjzD0+tgVQ69oXylcA2sHGw65k2Xl75eNO+Wy AKfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DMOxUZBxLgCDlsKrpJNHZ9FxZ68QqN09PcLcDEQAZqg=; b=rwNd3+Z9o8gJc/GImEPI1nkJeExqQoytzyBAV7UYZ2WAUuddGxN8coVUmXcdw9A0O0 BZdREtYSkprbW0ss9tAdEgsK42DDz+QpeRGStB2RTf0aQhIkENCZQlQlmFHcxUpoHf3N f1/dyQLqQnD6dGk2zBInZNh2z7GqoTT+33OQsoS4/zIvw/xu3bjc1GFOPoAPuaOunwf9 HY3LO0KK52C1/yu92hf6Yp1C53cPjKSaMahh8YdUvVosvacqrAqumVEAMTtQ4kuqVeqn ABegW6xWE3SL8t4EDJMpkOyJ65TjLfEsT1RA8GL+RorSBrFnRuP2GD2IW/nepfI4+DvF n7yA==
X-Gm-Message-State: AN3rC/7kGZhovLCM/DnkKdZBcfyloWB3coK3yshamTdLj5QAKA09nl16 ywymv9UvnTOQdwg5BDGBZFFBpxBBOw==
X-Received: by 10.36.46.81 with SMTP id i78mr355262ita.39.1492640761331; Wed, 19 Apr 2017 15:26:01 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Wed, 19 Apr 2017 15:26:00 -0700 (PDT)
In-Reply-To: <D95C67A4-AEBF-400B-A360-61C342FD6E4A@arrcus.com>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <9047A5A0-ED12-43C2-B2C5-D2A71CBB4373@arrcus.com> <D51D46A7.A9732%acee@cisco.com> <0A49219D-E721-4DA8-B9BF-A55C2FA36FBE@puck.nether.net> <D95C67A4-AEBF-400B-A360-61C342FD6E4A@arrcus.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 20 Apr 2017 00:26:00 +0200
X-Google-Sender-Auth: eC7WqvDzCut51HllT7GZKHVnzKQ
Message-ID: <CA+b+ER=hq0=JNRfF8VA76_aqeRMBCeyQm5aTbapysXGTgaGS_g@mail.gmail.com>
To: Keyur Patel <keyur@arrcus.com>
Cc: Jared Mauch <jared@puck.nether.net>, "Acee Lindem (acee)" <acee@cisco.com>, Hares Susan <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a114a93ce5b4754054d8c821f
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4Tm1pnjwkzyr5cckvlpKVgVQARc>
Subject: Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 19 Apr 2017 22:26:05 -0000

Keyur,

You can not set "insecure mode" before you reload the OS as current OS does
not have such knob. Unless you delay the deployment across N releases and
enforce sequenced upgrade.

The only way to prevent massive reachability failure upon reload due to
complete silent bgp prefix drop is to configure inbound policy for all EBGP
sessions before the reload and run with new image.

Of course this is all assuming that someone will read carefully the release
notes :)

If they do not the troubleshooting of this will be really painful ! CE will
see EBGP session as UP, will get all the routes and will send his routes.
CE will have no clue if PE dropped or accepted his routes. Likewise on the
other end .. Only imagine a network which has 10s of thousands of VPN CEs
as Bruno mentioned and their provider not following all releases CEs are
running.

At least doing it as part of OPEN msg will be immediately indicated to both
ends.

//R


On Thu, Apr 20, 2017 at 12:16 AM, Keyur Patel <keyur@arrcus.com>; wrote:

> And that would be good enough if that would allow exemptions of DC
> networks and any other networks that may need exemption.
>
> In that case I support the publication.
>
> Regards,
> Keyur
>
> On 4/19/17, 2:08 PM, "Jared Mauch" <jared@puck.nether.net>; wrote:
>
>     If someone sets insecure mode they can  e as promiscuous as they want.
>
>     That mode can have a very low bar IMO.
>
>     Jared Mauch
>
>     > On Apr 19, 2017, at 4:58 PM, Acee Lindem (acee) <acee@cisco.com>;
> wrote:
>     >
>     > I would agree with Keyur, For better or worse, our Cisco NX-OS BGP
>     > implementation does not require configuration of a peer policy.
>     >
>     > In fact, this requirement is contrary to some of the auto-discovery
>     > mechanisms we are exploring where only knowledge of the mutual
> address
>     > families is required.
>     >
>     > Thanks,
>     > Acee
>     >
>     > On 4/19/17, 4:43 PM, "Idr on behalf of Keyur Patel" <
> idr-bounces@ietf.org
>     > on behalf of keyur@arrcus.com>; wrote:
>     >
>     >> Thank you John for bringing it on IDR.
>     >>
>     >> As an update to RFC4271, I am not sure if I agree with the EBGP
> policy
>     >> configuration. There are lot of DC networks (for example) that use
> EBGP
>     >> within their CLOS. This extension may not be applicable in such
> networks.
>     >>
>     >> I would request authors to consider refining text to include
> appropriate
>     >> EBGP use cases and not make it generic for EBGP sessions (defined in
>     >> 4271).
>     >>
>     >> Regards,
>     >> Keyur
>     >>
>     >>
>     >> On 4/19/17, 9:49 AM, "Idr on behalf of John G. Scudder"
>     >> <idr-bounces@ietf.org on behalf of jgs@juniper.net>; wrote:
>     >>
>     >>   IDR folks,
>     >>
>     >>   As many of you have already noticed, draft-ietf-grow-bgp-reject-05
>     >> has completed GROW WGLC and is now in IETF LC.
>     >>
>     >>   As nobody other than Alvaro noticed (thank you for noticing,
> Alvaro!)
>     >> draft-ietf-grow-bgp-reject-05 represents an update to RFC 4271, in
> that
>     >> it mandates what a BGP implementation MUST do. See section 2 of the
> draft
>     >> for the details. It's short and easy to read.
>     >>
>     >>   If we had noticed this earlier, we would have either chosen to
> home
>     >> the document in IDR, or explicitly made an exception to have GROW
> do the
>     >> work. Given that we didn't, though, the plan is to continue
> progressing
>     >> the draft as a GROW document. However:
>     >>
>     >>   - As I understand it, the authors will add the Updates: 4271
> header
>     >> in addition to potentially taking in other comments from AD review.
>     >>   - If anyone has a strong objection to the unusual procedure,
> please
>     >> say so (either on-list, or to the chairs + AD).
>     >>   - Please send any last call comments to the IETF LC (see below)
>     >> although it's also OK to discuss here on the IDR list of course.
>     >>
>     >>   Many IDR participants are also active in GROW and have had their
> say,
>     >> but if you haven't, now's your chance.
>     >>
>     >>   Thanks,
>     >>
>     >>   --John
>     >>
>     >>> Begin forwarded message:
>     >>>
>     >>> From: The IESG <iesg-secretary@ietf.org>;
>     >>> Subject: Last Call: <draft-ietf-grow-bgp-reject-05.txt> (Default
>     >> EBGP Route Propagation Behavior Without Policies) to Proposed
> Standard
>     >>> Date: April 18, 2017 at 5:16:05 PM EDT
>     >>> To: "IETF-Announce" <ietf-announce@ietf.org>;
>     >>> Cc: grow-chairs@ietf.org, grow@ietf.org,
>     >> draft-ietf-grow-bgp-reject@ietf.org, christopher.morrow@gmail.com
>     >>> Reply-To: ietf@ietf.org
>     >>>
>     >>>
>     >>> The IESG has received a request from the Global Routing Operations
>     >> WG
>     >>> (grow) to consider the following document:
>     >>> - 'Default EBGP Route Propagation Behavior Without Policies'
>     >>> <draft-ietf-grow-bgp-reject-05.txt> as Proposed Standard
>     >>>
>     >>> The IESG plans to make a decision in the next few weeks, and
>     >> solicits
>     >>> final comments on this action. Please send substantive comments to
>     >> the
>     >>> ietf@ietf.org mailing lists by 2017-05-02. Exceptionally, comments
>     >> may be
>     >>> sent to iesg@ietf.org instead. In either case, please retain the
>     >>> beginning of the Subject line to allow automated sorting.
>     >>>
>     >>> Abstract
>     >>>
>     >>> This document defines the default behavior of a BGP speaker when
>     >>> there is no import or export policy associated with an External BGP
>     >>> session.
>     >>>
>     >>>
>     >>> The file can be obtained via
>     >>> https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-reject/
>     >>>
>     >>> IESG discussion can be tracked via
>     >>> https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-
> reject/ballot/
>     >>>
>     >>> This IETF LC, which originally concluded on 2017-04-18, is being
>     >>> extended to allow for additional input to be provided. Ops AD (for
>     >> GROW)
>     >>> and Routing AD (for IDR) wish to ensure that cross WG discussions
>     >> have
>     >>> had a chance to occur.
>     >>>
>     >>> No IPR declarations have been submitted directly on this I-D.
>     >>
>     >>   _______________________________________________
>     >>   Idr mailing list
>     >>   Idr@ietf.org
>     >>   https://www.ietf.org/mailman/listinfo/idr
>     >>
>     >>
>     >> _______________________________________________
>     >> Idr mailing list
>     >> Idr@ietf.org
>     >> https://www.ietf.org/mailman/listinfo/idr
>     >
>     > _______________________________________________
>     > Idr mailing list
>     > Idr@ietf.org
>     > https://www.ietf.org/mailman/listinfo/idr
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>