[Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)

[Brian Dickson <[e-mail]>]

On Sat, Nov 5, 2016 at 11:57 AM, Robert Raszuk <[e-mail]> wrote:

> ​​
>
>> ​​
>> However, given the heated discussion about prescribing a canonical
>> representation for -large-communities, is this a subject for an IDR rfc?
>>
>
> ​IMO it is. Reason being that RFC will be read by someone who is tasked to
> implement it and unless spec clearly at least recommends​ one way we will
> have a mix of behaviors.
>
>
>>
How about this: convert "Make it work exactly how you do RFC 1997" into an
I-D?


> I really do not recall any EBC where customer were successful in asking
> vendor to change any deployed defaults. Defaults once set during
> implementation usually stay for a long time.
>

My experience has been, unexposed defaults can clearly only be changed by
the vendor.
Mixing versions of code, which contain DIFFERENT defaults is fraught with
peril.
No sane customer would EVER ask a vendor for different unexposed defaults.

What I have always done is, ask/tell vendor: "Expose defaults explicitly in
configs. Give us knobs to change defaults globally."  Having knobs to
change defaults based on customer-provided values, solves the
consistent-defaults problem while giving the customer control over what
that default is.

While I am sure many customers ask several vendors for this, it has not
generally happened.

(Feel free to convey this back to your management, BTW.)



>
>
>> Is changing the language
>> ​
>> about propagating recognized transitive attributes going to change these
>> vendor's defaults?
>>
>
> ​Well I believe so. Notice that as much as folks likes large to be "like"
> 1997 it is not 100%. Even by your cisco example .. there is already
> send-community standard vs extended knob. Large ​will be new addition and
> in addition to "both" they will likely add also "all" keyword.
>

That is a vendor design decision issue.

There is nothing to prevent a vendor from implementing large, by making
large lock-step with 1997. For example, the implementation which supports
large, could apply different semantics to "send community" to send BOTH
1997 AND large communities, without changing the syntax.
(Such a change in semantics would probably be well advised to allow
optional parameters to provide knobs for "1997-only", "large-only",
"wide-only", "extended-only", or any combination of 1997, large, wide, and
extended).


> As to why we have this knob in the first place from the early days I
> recall it was based on ISPs who wanted to have RFC1997 local within their
> AS only by default - such that they do not need any extra policy in order
> not to propagate it over eBGP. Does the same design applies to Large ?
>

I don't recall any explanation for the default being the way it was. IMHO,
vendors are free to change THEIR default, but SHOULD apply the same default
to both 1997 and large.

Also IMHO, the "principal of least surprise" is something that vendors
should adhere to.
I cannot tell you how severely undisclosed and uncontrolled changes to
defaults across upgrades have adversely affected networks I built and ran,
and those of my compatriots.

Please, stop trying to make "better" defaults. Just give us the knobs.


> Note that I am not suggesting large must be propagate by default. But I
> think it would be good to have mandated by the spec consistency across BGP
> implementations - propagate or do not propagate.
>
>
Until the knobs are universally in place across vendors: No, and please
stop trying to advocate for this sort of thing.

Brian