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

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