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

Keyur Patel <keyur@arrcus.com> Wed, 19 April 2017 22:16 UTC

Return-Path: <keyur@arrcus.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 34EF012950A for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 15:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 3Q8EMbRxO8WX for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 15:16:24 -0700 (PDT)
Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 1DD75129BCE for <idr@ietf.org>; Wed, 19 Apr 2017 15:16:24 -0700 (PDT)
Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 8F48660059; Wed, 19 Apr 2017 22:16:21 +0000 (UTC)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from mx2-us4.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id B50788004C; Wed, 19 Apr 2017 22:16:20 +0000 (UTC)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp0177.outbound.protection.outlook.com [216.32.181.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx2-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id BF3B420077; Wed, 19 Apr 2017 22:16:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E0aeMM4zijWosLn6lf60D3mdMgutgEQSoGIPCgZ0KM8=; b=NDxseR5i1+jcuxQ53vlTf9WtYnnkN1wdwYofECeVBC2QG2gKaH24/tbhI8GP9DtJcArnvxIT/6roPERfVpzH7VzcB+wiQA9mO0gtaWxTF4rMwtK+ySXAkbZpSUY0oTZjWoagHAd/QXjKCqtR439QoCgUcCi1XRBIKy91YziQHrI=
Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Wed, 19 Apr 2017 22:16:14 +0000
Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.1034.018; Wed, 19 Apr 2017 22:16:14 +0000
From: Keyur Patel <keyur@arrcus.com>
To: Jared Mauch <jared@puck.nether.net>, "Acee Lindem (acee)" <acee@cisco.com>
CC: "John G. Scudder" <jgs@juniper.net>, "idr@ietf.org" <idr@ietf.org>, Hares Susan <shares@ndzh.com>
Thread-Topic: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
Thread-Index: AQHSuSz+QxMnaaMdpE6dWAZuvCqOqKHMs4OAgAB5mwCAAALIgP//nYOA
Date: Wed, 19 Apr 2017 22:16:14 +0000
Message-ID: <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>
In-Reply-To: <0A49219D-E721-4DA8-B9BF-A55C2FA36FBE@puck.nether.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: puck.nether.net; dkim=none (message not signed) header.d=none; puck.nether.net; dmarc=none action=none header.from=arrcus.com;
x-originating-ip: [2601:646:8981:c940:c9b1:9b87:e733:11bc]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR18MB0262; 7:khmgdwAl3PsRKdZBXADi6jzW3lg1ZHXTsMqhCKaW43DHrwcoxB83sTPQx04AolrEpLFikUAoWTTMK/rb1aY6DsKgqNknvf9e6BgJKgK+E16CBQu4EsM/EBgEDke9DESJr/pLC+9D2Y8wKv9kk+A1QzBsROxl0vpWy7uiSWdWimB6wCV4naMeMVmWRlYa5ss96xJqmMi+9D9t0ZKZQqcwXw/ttcsaay8WdMsTcmzkM2VsKoFCdDRqZrQuq1iKxMkPoP1v3R1x913TkH5di9/IWLJbfGckQW8EaMKwIkkAbko4KVojeErjHNW0PaaAULBtIhkNmVUNngYhhpvFEKhjjg==
x-ms-office365-filtering-correlation-id: 49851048-868d-49b2-5e5c-08d48771b16d
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075); SRVR:BY2PR18MB0262;
x-microsoft-antispam-prvs: <BY2PR18MB0262BEB59CB63C38B71C4812C1180@BY2PR18MB0262.namprd18.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(124276396282122)(120809045254105)(138986009662008)(95692535739014)(62015456732948);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(2002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(2016111802025)(20161123555025)(20161123564025)(6072148)(6043046); SRVR:BY2PR18MB0262; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0262;
x-forefront-prvs: 028256169F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(39830400002)(39410400002)(377454003)(377424004)(24454002)(6436002)(8676002)(83716003)(53546009)(8666007)(4326008)(38730400002)(53936002)(230783001)(6486002)(7736002)(2900100001)(345774005)(25786009)(189998001)(77096006)(6506006)(82746002)(3660700001)(3280700002)(122556002)(5660300001)(99286003)(6512007)(6246003)(8936002)(2906002)(229853002)(33656002)(54906002)(6306002)(6116002)(102836003)(50986999)(86362001)(81166006)(2950100002)(93886004)(305945005)(76176999)(54356999)(36756003)(50929005)(24704002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0262; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <212D199497048A418C741DE91566CDE8@namprd18.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 22:16:14.2680 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0262
X-MDID: 1492640181-wjcy6zXU7syw
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jVl0tG_Eaucxjp58GyD2X65TlNc>
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:16:26 -0000

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