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

[Brian Dickson <[e-mail]>]

Sent from my iPhone

> On Nov 5, 2016, at 4:13 PM, Jakob Heitz (jheitz) <[e-mail]> wrote:
> In my large-community code, I have lumped them under send-community-ebgp. At this point, I am very open to suggestions for configuration. Once the code is released, it gets much harder to change configs.

The following is my opinion, but I am confident that most operators concur with it:

Large is not a "new" attribute per se.
Large is providing parity for RFC1997, for use with 32-bit ASNs.

For that reason alone, the only sane implementation approach is "off by default", so as to be consistent with the default for 1997.

If someone does not use 1997 today, either choice would be okay.

However, for those using 1997, all of their BGP peering configs are well-baked, and whatever they use for managing them has 1997 built into it.

Those ASNs will be the early adopters and heaviest receive-side users (defining their name spaces in particular). When they ask for feature parity, that includes consistency with how they deploy and manage all types of communities.

Changing the default behavior between 1997 and large would likely cause chaos, anger, and frustration.

If anyone advocates for this change, it is clear they are not listening to operators, or do not understand what they want and why they want it. Operators who have 16-bit ASNs and use 1997, want to offer identical features as relates to 32-bit target ASNs. Operators with 32-bit ASN need this to do any 1997-type things, as clients (setting large communities) or as servers (receive-side handling). It augments 1997, and is not a new or different or separate thing.

I will give an example. Suppose a largish ISP has 1000 customers and 500 peers. They allow customers to send communities with only a standard config. However , they only send communities to a select few, and then only in highly customized configs. They don't send communities to peers, and do pass communities from customers up to their transit providers.

Making the default "on" instead of "off", means large communities will leak everywhere. Filtering will happen, but not everywhere at once. This will make it harder to track down the places where filtering should be done, since whether large communities show up may depend on path selection at any given moment. The attributes changing will induce BGP churn as updates propagate. That churn may in fact trigger load-induced brown-outs and further induce churn.

Note that all of the above occurs as soon as large communities are used, even if the ISP above was a 16-bit ASN with only 16-bit ASN peers.

In other words, it is conceivable that an unintended consequence could be a long-duration or even permanent instability to the global Internet.

The use case is, IMNSHO, not compelling, so please, let's keep the default the same as it is for 1997.

(But by all means provide knobs for changing the default for a single router.)

Brian