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

[Tony Przygienda <[e-mail]>]

Can't miss that food fight ;-) So couple observations:

i) as often, when an RFC tries to mandate anything beyond things on the
wire & the procedures to treat it, it tries ultimately to mandate
implementations and this is seldom wise
ii) +1 Enke, +1 Acee.  I understand operators here wanting "their default"
but large, diversified codebases have to serve (especially with BGP) a wide
spectrum of customers with different needs and with that, different
defaults make sense. And I remember routers booting up with a question list
of "press 1 if you're an evil syndicate, press 2 if you're a bedroom ISP,
press 3 if you think this is a toaster" to get the right defaults set ...

Having said that, I think this is BCP material at best and if this is a BCP
then

i) a "backward compatibility a.k.a which end of the stick is sharp" section
is very advisable
ii) the BCP should describe which customer segment is best served with
which default

--- tony

On Thu, Apr 20, 2017 at 11:08 AM, Brian Dickson <
[e-mail]> wrote:

> TL;DR: BCPs don't work; operators vary in experience, diligence, etc;
> vendors don't have common defaults; "open", "route-leaks", and "reject"
> work differently and are all needed; code changes will have a long tail of
> non-upgraded routers for a long time.
>
> BCPs don't work - see BCP38 for the canonical example.
>
> If operators were consistent (as in globally, uniform, ubiquitous without
> exception) in applying best practices, these proposals would not even
> exist. Their mere existence is proof that they are needed.
>
> "reject" will only help once implemented, on upgraded or newly deployed
> routers; ditto for "open"; "route-leaks" requires operator configuration,
> but uses a transitive-optional attribute (and thus works alongside
> non-upgraded routers). All three are needed, for their respective
> attributes (on by default; stop leak origination; limit leak propagation).
>
> The long tail on upgrades is what makes all three needed. No single one is
> sufficient by itself, unless/until every router has been upgraded AND
> configured. The three together are an imperfect but scalable and
> incrementally deployable set of improvements with real global results.
>
> Trying to move things in a productive direction.
>
> My $0.02.
>
> Brian
>
> On Thu, Apr 20, 2017 at 10:50 AM, Alvaro Retana (aretana) <
> [e-mail]> wrote:
>
>> Jared:
>>
>> Hi!
>>
>> Not everyone in this thread was part of the initial conversations we had,
>> so to give a little background:  I think (yes, still) that the document (as
>> is in -05) should be marked as updating rfc4271 because it starts off
>> saying that it “defines the default behavior of a BGP speaker…” and later
>> (Section 2) describes specific changes pointing at pieces of rfc4271:
>> “…MUST consider any routes advertised by an EBGP peer ineligible for route
>> selection (section 9.1.1 [RFC4271])…”.
>>
>> Again, what gives me heartburn and the reason this document caught my
>> attention is that change in the default – and from this thread, I can see
>> that is an issue for others.
>>
>>
>> Reading what you wrote below, about other potential options to achieve
>> the same result, I agree with you that the bar doesn’t have to be as high
>> as changing the default in rfc4271.  But the current document doesn’t
>> reflect that.
>>
>> Maybe what we need is to describe the solution in a way that is not so
>> rfc4271-specific.  Explain what the behavior should be (not how to achieve
>> it), and even talk about the operational pain, and what operators should
>> consider with the current not-specified behavior (which the document
>> doesn’t do much of now).  I think that would be a very different document
>> with a different set of discussion points, but one that could lead to the
>> goal.
>>
>> During the early thread of this draft (a couple of years ago), several
>> people suggested that the status should be a BCP.  I can see how a document
>> explaining the pains and the considerations for Internet routers could be a
>> BCP.
>>
>> Just trying to move the conversation forward.
>>
>> Alvaro.
>>
>>
>>
>> On 4/20/17, 12:07 PM, "Jared Mauch" <[e-mail]> wrote:
>>
>>         To make it clear: I don't want to break someones routers.
>>
>>         I do want to make it harder for someone to leak a table when they
>> have a new router.
>>
>>         I don't belive the bar should be high, it can be embedded in
>> whatever
>> configuration/ZTP/automation/cut+paste template out there.  It could come
>> in the form of yang over netconf, or a DHCPv6/DHCPv4 option.  It could
>> come from a TXT record in DNS, or wahtever configuration method the vendor
>> invents that is new and unimagined by th WG today.
>>
>>         I don't feel it requires updating 4271 to attain that goal, it's
>> clear implementors have seen a path to do this today without having
>> a concern with 4271, and I believe that Alvaro is wrong in the presumption
>> this document updates 4271.  (I'm also willing to be told that I'm too
>> rough
>> for consensus :-).
>>
>>
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>


-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky