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

[Robert Raszuk <[e-mail]>]

Hello Brian,

> The attributes changing will induce BGP churn as updates propagate.
> That churn may in fact trigger load-induced brown-outs and further
> induce churn.

BGP communities are not used in best path selection and their presence or
non presence have zero influence to change in bgp path selection hence no
direct relation to bgp churn what so ever (leave alone quote "permanent
instability to the global Internet").

If you are concerned that honoring by advertiser his own published
community will introduce BGP churn (as embedded actions may result in for
example AS_PATH prepend action) and that you are going to save the global
Internet by default filtering large communities  which otherwise may reach
the given's community advertising AS - it is your understanding on how BGP
works .. not mine.

Kind regards,
Robert.


On Sun, Nov 6, 2016 at 11:56 PM, Brian Dickson <
[e-mail]> wrote:

>
>
> 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