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

Jared Mauch <jared@puck.nether.net> Wed, 19 April 2017 21:08 UTC

Return-Path: <jared@puck.nether.net>
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 EDD9A12E852 for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 14:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 YHxe8aXS1ACF for <idr@ietfa.amsl.com>; Wed, 19 Apr 2017 14:08:48 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 60869129BE0 for <idr@ietf.org>; Wed, 19 Apr 2017 14:08:48 -0700 (PDT)
Received: from [IPv6:2603:3015:3603:8e00:34ee:4c74:5736:da2c] (unknown [IPv6:2603:3015:3603:8e00:34ee:4c74:5736:da2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 1EAB1540A90; Wed, 19 Apr 2017 17:08:44 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Jared Mauch <jared@puck.nether.net>
X-Mailer: iPhone Mail (14E304)
In-Reply-To: <D51D46A7.A9732%acee@cisco.com>
Date: Wed, 19 Apr 2017 17:08:43 -0400
Cc: Keyur Patel <keyur@arrcus.com>, "John G. Scudder" <jgs@juniper.net>, "idr@ietf.org" <idr@ietf.org>, Hares Susan <shares@ndzh.com>
Content-Transfer-Encoding: 7bit
Message-Id: <0A49219D-E721-4DA8-B9BF-A55C2FA36FBE@puck.nether.net>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <9047A5A0-ED12-43C2-B2C5-D2A71CBB4373@arrcus.com> <D51D46A7.A9732%acee@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1_2hpGcWqG-zBNeYliykk_CIMZc>
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 21:08:51 -0000

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