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 23:13 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 4D6E7128792 for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 16:13:36 -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 AAlBVdGyRsK5 for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 16:13:34 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 8CA0F1273E2 for <idr@ietf.org>; Wed, 19 Apr 2017 16:13:34 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id o22so45058502iod.3 for <idr@ietf.org>; Wed, 19 Apr 2017 16:13:34 -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=qWugX5H9tJMv8c1cbjpy9lSzrpCnuiXhHfca4AyZ2tA=; b=alievQD1QpQMkz3QkBfJspAFqrX+ibSbtuXSBwwTmywJCSwEMBoadPmIkFsg3qMoR2 F07eYLCkIPeb5yxilGYG+0Nk9YFta+uYfdMwWhDmSRmAQIZqvbLlqvVt1AmG/rKeBCcu lMxIt5DauNYRNwls/2h71n5Q9S6Ls0UBkr4d8n9MHfOAD0Ork/9MIj8W9nxRYvdoGKDp N44pkeAS9Y+yZOb1sCeogfT3bl31iLJPBze5aU2P3aZHPNppFMKSDDmyJuq/sY3deCCJ u99k1sNkk8UT2M1bypfRDKegOQ9ECEPAyxr9reuHnmwY6Ew1emD/k0EbdGwBpCb+Nlu+ +nAg==
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=qWugX5H9tJMv8c1cbjpy9lSzrpCnuiXhHfca4AyZ2tA=; b=rgksoOIsCoZdNinlY7BE7ODUV19Fy+o6h39az7WfKJS1Ul5sp/COMvUmiXD2cQsRbt XbLg84jHm+yeCSAQRr6Ot7jiv59Z2KA97496jhI00om8h3M15UP59W7BpixGRfSPiebb qQZtaSheZlMeT9jHSyQtNs5vAr8clX4D1aFIwgElKnh88Epohi5LCi4D507MXdNOjDAt xrfTl3qZGtS828Q1EKvilA8aaGKbpKyQETOopv//ZSSIMfqy94ygqpZV40EHJ2nBZX2S d2c3qAKwltBqAv4IKjEJ4u1y0TJdspVgj8iUDWNpOQqGVjiP+clA0iqE8QrTs4IOKZEC 0gcA==
X-Gm-Message-State: AN3rC/6ACOcnVeQnAd/lg1Q+qLhNpi0d58C+nWgkh6aUSJsiSSxKJGdi pXsYo76hdK8hpgcl6RTkvoChOTj+XA==
X-Received: by 10.107.140.10 with SMTP id o10mr6659357iod.139.1492643613201; Wed, 19 Apr 2017 16:13:33 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Wed, 19 Apr 2017 16:13:32 -0700 (PDT)
In-Reply-To: <abe393d3-d1e4-7841-4620-38dab751765b@cisco.com>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <abe393d3-d1e4-7841-4620-38dab751765b@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 20 Apr 2017 01:13:32 +0200
X-Google-Sender-Auth: ucVs_1vU0DcvbTD9ltNnvVlUs2o
Message-ID: <CA+b+ERnRz8BEO3mb1fnsDPoiL6Wxjdfw9vQPbyODNEa+xCJdnw@mail.gmail.com>
To: Enke Chen <enkechen@cisco.com>
Cc: "John G. Scudder" <jgs@juniper.net>, idr wg <idr@ietf.org>, Hares Susan <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=94eb2c06084c575bc3054d8d2c46
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/agvqOyLZ-6Cm-THSezQHnOGu44w>
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 23:13:36 -0000

Hi Enke,

100% agreed. I said the same to authors offline earlier today as well.

Every time you define a new AFI/SAFI one can make such AFI/SAFI mandatory
to have an inbound policy or not.

If authors would go that far and define new AFI/SAFI for IPv4 and IPv6
unicast so be it. The defaults there may be changed by such spec :) And
once accepted such new AFI/SAFI may share the routes with 1/1 & 2/1 for
IBGP propagation too.

Making it a Standards Track doc for all SAFIs MP-BGP is used today seems
like a pretty bad idea.

And as far as deployment practice we already have BCP document on this for
a while ... See section 6.3.1 of BCP194

REF: https://tools.ietf.org/html/bcp194#section-6.3.1

Cheers,
R.


On Thu, Apr 20, 2017 at 12:53 AM, Enke Chen <enkechen@cisco.com>; wrote:

> Hi, Folks:
>
> The document defines or changes the "default behavior" for EBGP.  However,
> the default
> behavior for a particular code base or release was set long time ago, and
> in some cases
> more than 20 years ago. To avoid breaking existing deployment in this
> case, the default
> behavior in the code can not be changed (with or without this document).
> Then it becomes
> a deployment practice for the policies to be configured.
>
> So it seems to me that "Standard Track" may not be the right
> classification for this
> document.  "Deployment recommendation or Practice" might be more
> appropriate.
>
> Thanks.  -- Enke
>
> On 4/19/17 9:49 AM, John G. Scudder 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
>