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

[Job Snijders <[e-mail]>]

Hi Bruno,

You create a false dilemma stating that it is not clear to you whether
this is a "requirement draft or a solution draft", and that those need
to be separate. 

Did you review Alvaro's suggested changes which prompted the third IDR
consultation on this topic? They are viewable here:

    http://htmlpreview.github.io/?https://github.com/jaredmauch/draft-mauch-bgp-reject/blob/alvaro/draft-ietf-grow-bgp-reject-06-from-5.diff.html

I'm disappointed that you've taken a CLI example I've provided as the
sole driver behind this effort. I did not mean to offer the CLI example
as an exhaustive list of reasons.

Kind regards,

Job

ps. For additional advise on how to derail this effort, let us please
take the ideas offered in
http://www.businessinsider.com/oss-manual-sabotage-productivity-2015-11?international=true&r=US&IR=T
also in consideration.

On Fri, Apr 21, 2017 at 08:20:47AM +0000, [e-mail] wrote:
> > From: Eric C Rosen  > Sent: Thursday, April 20, 2017 10:01 PM
> > 
>  > On 4/20/2017 2:24 PM, Tony Przygienda wrote:
>  > > Can't miss that food fight ;-)
>  > 
>  > It did seem to degenerate rapidly into "if you don't agree with my
>  > proposal, you don't care about security".  ;-(
>  > 
>  > I agree with Enke that surprising your customers with a change in
>  > behavior due to altered defaults is generally considered to be a big no-no.
>  > 
>  > When the customers complain about a change in behavior, it is not
>  > considered appropriate to respond with "it's not my fault, you should
>  > have read the release notes", or "it's not my fault that you don't know
>  > how to troubleshoot BGP", or "it's not my fault that you didn't do your
>  > due diligence".
>  > 
>  > Phasing in a change of behavior over several releases is not a practical
>  > solution, because:
>  > 
>  > a) Customers will still be surprised when the default behavior finally
>  > changes, and
>  > b) Many customers won't deploy all the releases anyway.
>  > 
>  > >
>  > > 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
>  > 
>  > I would agree that something more than "figure out how to configure the
>  > new release to behave like the old release" would be helpful.
>  > 
>  > > ii) the BCP should describe which customer segment is best served with
>  > > which default
>  > >
>  > 
>  > But then operators from different segments would have to get together to
>  > understand each others' requirements, and they'd have to respect each
>  > others' opinions as well.   I can't wait to see what happens when the
>  > "trust nobody" folks get together with the "zeroconfig plug and play"
>  > folks ;-)
>  > 
>  > The dilemma is that there is a real security problem in certain
>  > environments, but the proposed solution seems to have unintended
>  > side-effects that are problematic.  Then the question becomes whether
>  > the benefits are worth the cost, and this is not really a question that
>  > can be resolved by IETF consensus.
> 
> Good summary, thanks.
> 
> 1) As already asked, could the draft states what the problem it aims at solving?
> In particular,
> - it does not solve the general route leak problem, nor the 3 problems indicated in the first section of the introduction.
> - on the list, one author expressed a different, more focused/pragmatic, goal
> " The problem is that there are some platforms which _immediately_
> activate a line of configuration after you press enter, and a BGP
> session may already come up before you get to the configuration line
> which restricts what should be announced or accepted."
> 
> 2) Can the draft document the side-effects, e.g. in a manageability section.
> 
> 
> Without those 2 points, IMHO the draft is misleading for the reader/reviewer/voter/user. This trade-off analysis is currently absent in the document up to the point that those drawbacks have not been raised during RTG-DIR and RTG-OPS review. So it's probably fair to assume that this may also have missed by some other IETF contributors.
> 
> 3) Once the problem that we want to solve has been clarified (cf 1) , then we can start reviewing the solution.
> In particular, if the problem is indeed:
> " The problem is that there are some platforms which _immediately_
> activate a line of configuration after you press enter, and a BGP
> session may already come up before you get to the configuration line
> which restricts what should be announced or accepted."
> 
> Then, there might be other solutions. e.g.
> - fixing this CLI issue on those plateforms. In particular, no need to also impact the netconf provisioning which has not this issue, or the implementations which do not have such CLI issue.
> - use a 2 step provisioning on both EBGP peers:
>    - on the sending side, use a trick for avoid the session to come up until the BGP configuration is complete enough . e.g. interface shut, use the wrong authentication key/TTL hack
>    - on the receiving side, use a trick to avoid the session to successfully come up or to accept the routes. Then after allowing for a reasonable time to let the sender finish its config, restore the correct configuration. Obviously this can be automated by a "controller", a local feature, a local event script.
> This 2 step provisioning has the benefit of limiting the cost of the solution to the space where the problem is. (vs asking everyone to bear the cost, for a benefit of a few, whatever important is this use case)
> - I sure others may find more creative solutions.
> 
> 4) Regarding the specific solution proposed in the draft,
> -  why has it been prefer to silently drop the route, with will surprise people and definitely the EBGP peer, rather than bringing done the BGP session with a reasonable error (sub)code / text to help diagnose the problem.
> 
> - the 3rd bullet is debatable to me
> "   o  A BGP speaker SHOULD fall back to an "import nothing" and "export nothing" mode following failure of internal components, such as a policy engine."
> This is an error handling situation. IMHO https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-07 had a better analysis on this point. e.g. at the minimum, rather than calling for silently dropping the route, I would call for closing the BGP session, possibly trying to restart it. Plus if this BGP internal failure also impact IBGP session, we have a bigger problem.
> 
> - it's not clear whether this draft is a requirement draft or a solution draft. As per the first sentence of section 2 and its further text, it looks like a requirement draft. But in this case, the requirements should be solution agnostic. Which is definitely not the case. (e.g. above comments are solutions specific)
> 
> Thanks,
> Regards,
> -- Bruno