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 <[e-mail]>]

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" <[e-mail]> 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) <[e-mail]> 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" <[e-mail]
    > on behalf of [e-mail]> 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"
    >> <[e-mail] on behalf of [e-mail]> 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 <[e-mail]>
    >>> 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" <[e-mail]>
    >>> Cc: [e-mail], [e-mail],
    >> [e-mail], [e-mail]
    >>> Reply-To: [e-mail]
    >>> 
    >>> 
    >>> 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
    >>> [e-mail] mailing lists by 2017-05-02. Exceptionally, comments
    >> may be
    >>> sent to [e-mail] 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
    >>   [e-mail]
    >>   https://www.ietf.org/mailman/listinfo/idr
    >> 
    >> 
    >> _______________________________________________
    >> Idr mailing list
    >> [e-mail]
    >> https://www.ietf.org/mailman/listinfo/idr
    > 
    > _______________________________________________
    > Idr mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/idr