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

From: Brian Dickson <[email-masked]>
Date: Sat, 5 Nov 2016 12:52:50 -0700

On Sat, Nov 5, 2016 at 11:57 AM, Robert Raszuk <[email-masked]> 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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 5 Nov 2016 23:13:46 +0000

IOS-XR does not send communities or extended communities to eBGP neighbors by default.
To send communities, you need to configure
  send-community-ebgp
Under the neighbor address-family.
To send extended communities, you need to configure
  send-extended-community-ebgp

The reason is that many operators use communities internal to an AS for many reasons and we don't want these to accidentally leak out to the wider internet. If an operator intends to send communities outside of their own AS, then they need to make a conscious decision to do so. Along with that conscious decision, they should filter out all the internally used communities in a route-policy.

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.

Thanks,
Jakob.

On Nov 5, 2016, at 12:53 PM, Brian Dickson <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Nov 5, 2016 at 11:57 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> 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.

Is changing the language
​

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

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.

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
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 6 Nov 2016 00:16:04 +0100

Hi Jakob,

Would you mind to elaborate how do you plan to address IOS XE BGP code base
concerning the same topic ?

Thx,
R.

On Sun, Nov 6, 2016 at 12:13 AM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> The reason is that many operators use communities internal to an AS for
> many reasons and we don't want these to accidentally leak out to the wider
> internet. If an operator intends to send communities outside of their own
> AS, then they need to make a conscious decision to do so. Along with that
> conscious decision, they should filter out all the internally used
> communities in a route-policy.
>
> 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.
>
> Thanks,
> Jakob.
>
>
> On Nov 5, 2016, at 12:53 PM, Brian Dickson <[email-masked]>
> wrote:
>
>
>
>> ​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.
>>
>>
>>>
> What I have always done is, ask/tell vendor: "Expose defaults explicitly
> in configs. Give us knobs to change defaults globally."  Having knobs to
> [email-masked]

---

From: heasley <[email-masked]>
Date: Sun, 6 Nov 2016 04:08:49 +0000

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

If you consider draft-grow-bgp-reject, does that change your opinion about
filtering needing to be the default?

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sun, 6 Nov 2016 05:43:42 +0000

It does not change my opinion. My opinion is that we should filter by default at the EBGP boundary. IOS-XR does that. Cisco recognized the problem addressed by draft-grow-bgp-reject back when IOS-XR was designed. Unfortunately, it was too late to change the default in IOS. If IOS changes that default, it would break many existing deployments.

Thanks,
Jakob.

> On Nov 5, 2016, at 9:08 PM, heasley <[email-masked]> wrote:
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sun, 6 Nov 2016 05:50:01 +0000

I cannot tell you that Robert.

Thanks,
Jakob.

On Nov 5, 2016, at 4:16 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jakob,

Would you mind to elaborate how do you plan to address IOS XE BGP code base concerning the same topic ?

Thx,
R.

On Sun, Nov 6, 2016 at 12:13 AM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
IOS-XR does not send communities or extended communities to eBGP neighbors by default.
To send communities, you need to configure
  send-community-ebgp<http://send-community-ebgp>
Under the neighbor address-family.
To send extended communities, you need to configure
  send-extended-community-ebgp<http://send-extended-community-ebgp>

Thanks,
Jakob.

Is changing the language
​

Brian

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 6 Nov 2016 14:42:58 -0500

On Sun, Nov 06, 2016 at 05:43:42AM +0000, Jakob Heitz (jheitz) wrote:
> Unfortunately, it was too late to change the default in IOS. If IOS
> changes that default, it would break many existing deployments.

This is a point I'm also strongly sympathetic to.  Changing the core
defaults is simply Not Done.  

Supporting such default changes will likely have to be done via a new knob
that imposes a new set of defaults.  Admittedly, not fully "default" since
you have to configure something, but at least something that changes
expectations.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 6 Nov 2016 22:50:24 +0100

Hi Jeff,

Just to clarify my intention here ...

I really wanted to make sure that large is deployed with defaults which
make most sense and such defaults are identical between implementations.
And we can do it now or never as when the code is shipped out in first
production release the gave is over.

When I mentioned RFC1997 it was only due to heavy influence by some for the
enforcement of functional symmetry between standard and large communities.
As far as propagation defaults IMO they do not need to be identical.

Bottom line I am not advocating to change RFC1997 propagation rules. Only
to define one way or another what should be such rules regarding large
communities if implementation recognizes the new attribute and no policy is
in place to overwrite the default behavior.

Thank you,
Robert.

---

From: Brian Dickson <[email-masked]>
Date: Sun, 6 Nov 2016 14:56:24 -0800

Sent from my iPhone

> On Nov 5, 2016, at 4:13 PM, Jakob Heitz (jheitz) <[email-masked]> wrote:

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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Nov 2016 00:16:41 +0100

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 <
[email-masked]> 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.
>
> For that reason alone, the only sane implementation approach is "off by
> default", so as to be consistent with the default for 1997.
>
> 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.
>
> 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.
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sun, 6 Nov 2016 23:25:27 +0000

The question:
Should Large Communities be transmitted across EBGP by default?

Note: there is a knob to change the default, so the discussion is how to act with the knob unconfigured.

Arguments to block:
1. Principle of least surprise: Do same as 1997.
2. Accidental leakage of internally used communities will cause unintended routing.

Arguments to pass:
1. Legacy code will pass it, because the attribute is transitive. Upgrade to LC aware code should do the same by default.
2. It is convenient to pass a community through your first level transit to fix a problem further upstream. A default block frustrates this effort.

The problem of accidental leakage is greater with 1997 communities, because many ISPs use private ASNs. This is as problem if a community intended for a distant ISP is interpreted by a near ISP when they use the same private ASN. This problem SHOULD disappear with Large Communities, because the need to use private ASNs no longer exists.

I would like to hear other arguments and gauge support for each case.

Thanks,
Jakob.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Nov 2016 00:30:49 +0100

Hi Jakob,

Very fair and good summary !

One question: What is "unintended routing" ? Are you alluding to "churn" If
so pls see my reply to previous post.

Just to reiterate ... I do recommend that whatever option gets more support
it should be spelled out in the Large Community RFC such that all
implementations can be consistent.

Best,
Robert

On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> 1. Legacy code will pass it, because the attribute is transitive. Upgrade
> to LC aware code should do the same by default.
> 2. It is convenient to pass a community through your first level transit
> to fix a problem further upstream. A default block frustrates this effort.
>
> The problem of accidental leakage is greater with 1997 communities,
> because many ISPs use private ASNs. This is as problem if a community
> intended for a distant ISP is interpreted by a near ISP when they use the
> same private ASN. This problem SHOULD disappear with Large Communities,
> because the need to use private ASNs no longer exists.
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 7 Nov 2016 00:04:11 +0000

An example of unintended routing:
Both AS2914 and AS49544 use the private ASN 65501 to prepend one time.
If a route using 65501 in the community traverses both these ASes, then each AS will prepend, resulting in (likely unintended) double prepending.
https://onestep.net/communities/as2914/
https://onestep.net/communities/as49544/

Thanks,
Jakob.

On Nov 6, 2016, at 3:30 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jakob,

One question: What is "unintended routing" ? Are you alluding to "churn" If so pls see my reply to previous post.

Just to reiterate ... I do recommend that whatever option gets more support it should be spelled out in the Large Community RFC such that all implementations can be consistent.

Best,
Robert

On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
The question:
Should Large Communities be transmitted across EBGP by default?

Arguments to block:

Arguments to pass:

Thanks,
Jakob.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Nov 2016 01:12:18 +0100

Isn't the main motivation of LC to avoid overloading the target ASN with
private ASN values to embed the action ?

Besides both are applicable to their directly connected customers so really
regardless of the default those should be dropped by policy after
execution/application.

Thanks,
R.

On Mon, Nov 7, 2016 at 1:04 AM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> If a route using 65501 in the community traverses both these ASes, then
> each AS will prepend, resulting in (likely unintended) double prepending.
> On Nov 6, 2016, at 3:30 PM, Robert Raszuk <[email-masked]> wrote:
>
> Hi Jakob,
>
> Just to reiterate ... I do recommend that whatever option gets more
> support it should be spelled out in the Large Community RFC such that all

---

From: [email-masked]
Date: Mon, 07 Nov 2016 02:06:38 +0100

Worse still, if a certain ISP is dualhomed one could make the prefix partially unreachable for a significant portion of the Internet. Say that AS49544 would be multihomed between AS2914 + AS3356 and a customer of the first network sets 65500:3356, then both networks would not export to AS3356. Because neither AS2914 nor AS3356 buys transit, the result would be that singlehomed customers of AS3356 don't receive the prefix at all. Fortunately, that problem goes away with Large Communities thanks to the Global Administrator field. Jakob, I think this addresses your 2nd "argument to block". 

Continuing my argument, today's routers (at least Brocade) have the following default behaviour when handling RFC1997 communities: accept everything, but don't pass it on to your neighbors, neither iBGP nor eBGP. Of course that default doesn't work for us since the former would pose a security risk, and the latter would effectively break any community system. Since any neighbor can unilaterally enable send-community to begin transmitting RFC1997 communities, an ISP writing any kind of routing policy involving BGP communities must already decide for themselves how they're going to handle the receipt of a community tag from their neighbors (ignore, sanitize, pass through, etc). On the other hand, if an ISP doesn't use BGP communities in their routing policy at all the attribute means nothing and can (should?) be passed on transparently. Especially in case of Large Communities where legacy code will already behave that way. 

The takeaway from all this is that it's harmless to send communities by default. I think it's beneficial to receive as much information from your neighbors as possible. It makes debugging easier and could allow for receiving ISPs to optimise routing policy. 

Best regards, 
Martijn Schmidt 

On 7 November 2016 01:04:11 CET, "Jakob Heitz (jheitz)" <[email-masked]> wrote:
>On Nov 6, 2016, at 3:30 PM, Robert Raszuk
><[email-masked]<mailto:[email-masked]>> wrote:
>
>Hi Jakob,
>
>One question: What is "unintended routing" ? Are you alluding to
>"churn" If so pls see my reply to previous post.
>
>support it should be spelled out in the Large Community RFC such that
>all implementations can be consistent.
>
>Best,
>Robert
>
>
>On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz)
><[email-masked]<mailto:[email-masked]>> wrote:
>The question:
>1. Legacy code will pass it, because the attribute is transitive.
>Upgrade to LC aware code should do the same by default.
>2. It is convenient to pass a community through your first level
>transit to fix a problem further upstream. A default block frustrates
>this effort.
>
>intended for a distant ISP is interpreted by a near ISP when they use
>the same private ASN. This problem SHOULD disappear with Large
>Communities, because the need to use private ASNs no longer exists.
>
>------------------------------------------------------------------------
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Brian Dickson <[email-masked]>
Date: Sun, 6 Nov 2016 19:46:10 -0800

Sent from my iPhone

> On Nov 6, 2016, at 4:12 PM, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Isn't the main motivation of LC to avoid overloading the target ASN with private ASN values to embed the action ? 

It may be the motivation for having 3 x 32-bits, but the MAIN motivation is support for 32-bit ASNs.

It might be the case that initial deployment could incorporate 16-bit ASNs in 32-bit fields, including private ASNs.

Those using 1997 might want to migrate to large-only, rather than continue supporting both large and 1997. That migration could start with accepting both (1997 and large-encoded 1997 of 0000ASN16:0000ASN16:0), having customers add or switch to large, and then dropping 1997 support.

So, let's consider the implications of having large be sent by default, vs not.

When customers add the large communities, they will go everywhere if they don't filter, i.e. if they aren't aware of the need to filter large communities.

So, why would that migration be expected or considered reasonable, if the long term goal of LC is GA:target:action? Because it is the simplest, cleanest, and safest path. 

Having 1997 and large simultaneously used means possible corner cases or inconsistencies can occur. 

Once the 1997 semantics are transliterated, only then can real LC be implemented on the receiving side.

That would involve two windows of overlap: 1997 to transliterated; and transliterated to "real" LC.

And in both windows, the 1997-semantics large communities can collide, just like the conflicting cases Jakob listed.

That issue is a non-issue if the default is "off".

> Besides both are applicable to their directly connected customers so really regardless of the default those should be dropped by policy after execution/application. 

I believe this is called "blaming the victim".

There is no easy way to tell how many such conflicts would be exposed by default "on".

20 years of  RFC1997. All with default off. 20 years of industry consolidation, staff turnover, undocumented implementations. 

Assuming that no migration will occur, isn't helpful. Changing the default behavior across such migration is the risk.

Having the same behavior for large guarantees zero incremental risk, which is why I am advocating for it.

Brian

>> On Mon, Nov 7, 2016 at 1:04 AM, Jakob Heitz (jheitz) <[email-masked]> wrote:
>>>> On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz) <[email-masked]> wrote:
>>>> The question:

---

From: Peter Hessler <[email-masked]>
Date: Mon, 7 Nov 2016 11:23:06 +0100

On 2016 Nov 06 (Sun) at 22:50:24 +0100 (+0100), Robert Raszuk wrote:
:I really wanted to make sure that large is deployed with defaults which
:make most sense and such defaults are identical between implementations.
:And we can do it now or never as when the code is shipped out in first
:production release the gave is over.
:

In OpenBGPD our default is to propagate communities; normal, extended,
and large.

We have no intention on changing that default.

Additionally, I see no reason why implementations should be have
identical defaults.  Cisco is not OpenBGPD, OpenBGPD is not Huewai, and
Huewai is not Quagga.

This is implementation specific, and has nothing to do with the
standardization process.

-- 
I am so optimistic about beef prices that I've just leased a pot roast
with an option to buy.

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Nov 2016 13:10:05 +0100

Hi,

>   send-extended-community-ebgp

This would work for our use case - "1997 and large" is "the standard
community to be sent to upstreams and customers", while "extended" is
"something special, only to used in particular cases".

I consider "large" to be "the logical extension to 1997", so I do not
see a reason to operationally differenciate here ("1997-only" or 
"large-only").

[..]
> In my large-community code, I have lumped them under send-community-ebgp. 

Works for us.

Gert Doering
        -- Operator, some exposure to BGP in the past
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Nov 2016 13:12:51 +0100

Hi,

On Mon, Nov 07, 2016 at 12:16:41AM +0100, Robert Raszuk wrote:
> BGP communities are not used in best path selection 

While the communities *themselves* are not, many (most? all?) major transit
providers offer communities to influence the value local-pref is set to,
on ingress from their customers.

So, if a customer sends 5539:70 or 5539:130 to us, this will end up 
setting local-pref 70 or local-pref 130, and that *will* influence 
path selection.

So, while your statement is true, it's lacking real-world consideration.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Nov 2016 13:14:59 +0100

Hi,

> filtering needing to be the default?

IOS XR is doing exactly that.  What is your point?

Gert Doering
        -- NetMaster

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Nov 2016 13:18:44 +0100

Gert,

My example was very clear and I provided example of AS_PATH prepend.

The point which you are missing is that if you execute community you should
clean up and delete it. Blind default on or off is not the way to stop
propagation of selected communities.

And if someone is inserting 5539:* it seems obvious that the intention is
that such community should get to 5539.

Best,
R.

---

From: Jared Mauch <[email-masked]>
Date: Mon, 7 Nov 2016 07:22:46 -0500

> On Nov 6, 2016, at 1:43 AM, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 
>  it would break many existing deployments.

I think you mean bring security to these deployments.

Advocating for this is like advocating to keep ip directed-broadcast or open relays on the internet.  It’s a security risk to the ecosystem imposed by a vendor blindly saying “change is hard, my customers can’t handle the technology they use”.

- Jared

---

From: "Dickinson, Ian" <[email-masked]>
Date: Mon, 7 Nov 2016 12:30:25 +0000

Hi Robert,

>The point which you are missing is that if you execute community you should clean up and delete it.
>Blind default on or off is not the way to stop propagation of selected communities.
>And if someone is inserting 5539:* it seems obvious that the intention is that such community should get to 5539.

I would suggest that "clean up and delete" is not representative of all current usage that I know of.
The community is often left in place to show why a change in behaviour was triggered e.g. raising local preference.
This aids troubleshooting within IBGP and for downstream ASNs.

Ian

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Nov 2016 14:05:13 +0100

Hi,

> This aids troubleshooting within IBGP and for downstream ASNs.

What Ian says.

Gert Doering
        -- NetMaster

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 7 Nov 2016 10:21:27 -0500

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

If that's what your vendor does with its 1997 implementation, being
consistent is reasonable.

That's not what our implementation will do, for the same reason.

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 7 Nov 2016 16:14:32 +0000

On Nov 7, 2016, at 4:19 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Not always true.

5539:100 is used by 5539 to tell its neighbors that the route was learned in Frankfurt/DECIX.
http://www.space.net/static/bgp_communities.html

Thanks,
Jakob.

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Nov 2016 17:20:59 +0100

Hi,

> http://www.space.net/static/bgp_communities.html

Indeed, and sorry for the 5539:70 and 5539:130 example, these were 
obviously incorrect - the list (and our configs) say it's 5539:3070,
5539:3100 and 5539:3130 to set local-pref in our network.

But this example prominently documents why operators think that the model
"5539 defines the namespace for 5539:*" is the only thing that makes sense
- there are communities set *by* 5539, to declare "information about a 
prefix", and there are other community values sent *to* 5539 to cause some 
sort of policy effect in our network, but both have to be declared by 
5539 to be a valid reflection of our configured BGP policy.

2914:5539 would not have any meaning for us, even if it might tell 2914
"do not announce to 5539" or anything else - not our namespace.

Gert Doering
        -- NetMaster

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Nov 2016 17:35:18 +0100

Jakob,

> that such community should get to 5539.

​I was hoping it is obvious that "someone" means "someone other then 5539"
which now makes it always true in the above.

For the reverse direction not sure if say at GROW or NANOG/RIPE there could
not be common agreement that for informational announcements associated
with given route first 4 octets of LC should be marked with well understood
by everyone value say 0xFFFFFFFE (4294967294).

Thx,
r.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 7 Nov 2016 11:42:02 -0500

Gert,

> On Nov 7, 2016, at 11:20 AM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

The general issue is that the context for the use of the community is a bit overloaded.  

If the namespace, e.g. AS 5539, has communities meant to be addressed *to* it and it also has communities internal that it sets itself, it likely should use 5539:*:* for both.  The thing that keeps the properties of the externally originated and internally originated would have to be the Local1:Local2.  Enforcement of this can be done via import policy dropping internal communities at ASBRs.

The same would hold for items attached by the context AS as information for external consumers.  Unfortunately, nothing stops an external party from attaching such a community; it's up to the downstream consumer to check the AS_PATH to see if the route has transited 5539 and to hope that none of the intervening routers have added 5539 internal communities.  

With regard to the internal vs. externally added routes, this is part of the motivation in the common header in the wide communities draft.  In that header, the SRC AS is the one attaching the community whereas the Context AS is how you interpret it.  Externally vs. internally attached communities are clear in that case, although with no additional protections against maliciously setting values in the protocol.

-- Jeff (and even SIDR wasn't willing to touch that in their first pass...)

---

From: Job Snijders <[email-masked]>
Date: Mon, 7 Nov 2016 18:05:47 +0100

Hi,

While some keep trying to add to or change Large Communities, others are
going ahead and are deploying Large Communities for the benefit of their
respective operational communities. This here is the real news:

    "INEX has become the first organisation in the World to enable BGP
    Large Communities in production"

    source: https://twitter.com/ComePeerWithMe/status/795670632243625986

We should focus on publishing draft-ietf-large-community instead of
deviating into topics which can be handled after we've gleaned more
experience with the technology.

Regards,

Job

---

From: heasley <[email-masked]>
Date: Mon, 7 Nov 2016 17:38:11 +0000

> IOS XR is doing exactly that.  What is your point?

XR is Jakob's attention, but IOS{-XE} and others do not.  but, the point is
that if, by implementing that draft (or by having already implemented that
draft in the case of XR), the implementation is not leaking communities (or
any NLRI) and requires RPL to do so.

Since the suggested argument for existance of this 'send-communities' knob
was to require configuration to send-communities - it is redundant, policy
is already required to send (or rx) any NLRI.

Not sending communities by default is a problem for leaf networks (eg CLECs,
regional telephone companies) that are behind ISPs who do not understand
routing well.  I do not see a disadvantage (or sum of) that is greater than
this advantatge.

---

From: t.petch <[email-masked]>
Date: Mon, 7 Nov 2016 17:40:56 +0000

----- Original Message -----
From: "Peter Hessler" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 07, 2016 10:23 AM

> This is implementation specific, and has nothing to do with the

Peter

I think that that is spot on.

Customers will expect consistent behaviour from a supplier (and equally
should be prepared for change if and when they change supplier).

Of course, it may not always be that straightforward as implementations
need to interoperate, first and foremost; but if they have been doing
that, albeit not following the precise specification of a transitive
attribute, then I think that consistency is what is needed.

Tom Petch

---

From: heasley <[email-masked]>
Date: Mon, 7 Nov 2016 19:11:06 +0000

> So, while your statement is true, it's lacking real-world consideration.

I do not understand this churn argument as it applies to large-communities.

The receiving party has to take action - ie: create policy to act upon the
large-communities - for them to affect route-selection.  There may be one
IX that is the only AS on earth that currently supports large-communities.
if large-communities are sent by default today, they only affect the size of
RIBs and size and number of BGP messages - and possibly that IX.

the only communities that take effect without adding policy are the
well-knowns and they are not present without policy to add them - and
there are no well-known large-communities.

---

From: heasley <[email-masked]>
Date: Mon, 7 Nov 2016 20:25:54 +0000

> It may be the motivation for having 3 x 32-bits, but the MAIN motivation is support for 32-bit ASNs.

both of these are motivations for -large-; support 32-bit ASNs AND stop
over-loading.

> It might be the case that initial deployment could incorporate 16-bit ASNs in 32-bit fields, including private ASNs.

What?  is there a case where a 16bit ASN doesnt fit in 32bits?

> 20 years of  RFC1997. All with default off. 20 years of industry consolidation, staff turnover, undocumented implementations. 

20 years in that implementation...

> Having the same behavior for large guarantees zero incremental risk, which is why I am advocating for it.

given a BGP topology of AS1 - AS2 - AS3, where AS1 & 3 recognize LCs and
AS1 sends LC 3:n:n to affect their local-pref (or whatever), this will
potentially break when AS2 updates to an o/s that recognizes LCs.  surprise!

---

From: Brian Dickson <[email-masked]>
Date: Mon, 7 Nov 2016 12:38:44 -0800

On Mon, Nov 7, 2016 at 9:40 AM, t.petch <[email-masked]> wrote:

> [snip]
What I think need to be (re-)emphasized, and which is the reason I started
this thread:
Interoperability is an issue, both INTRA-ASN as well as INTER-ASN.

Incremental deployability in a heterogenous environment, of an incremental
method for supporting an existing function, is something that requires
operator control.

So, while defaults matter, knobs to control those behaviors matter more.

Say someone has a network with vendors X, Y, and Z. Say they use RFC1997
communities substantially, and want to deploy LC.

Doing so requires incrementally upgrading some subset of routers, with
several iterations. Some of those upgrades are likely to be "some of X
only", etc.

Without a knob to disable (or possibly enable) propagation of LC, when
doing an upgrade to a version where LC is understood (on a single router),
the behavior will depend entirely on what vendor X's upgraded code does.

I don't consider that sufficiently constrained behavior for an incremental
upgrade. Not having a knob means either "random behavior", or "flag day"
(requiring simultaneous upgrades to all routers of all vendors).

What matters to me, as an operator, is that I can control all my routers,
especially if the default behavior of each router "flavor" differs, and
most especially if that behavior differs across software versions.

Most of the discussion has presumed homogenous ASNs, which is not
universally the case (and in my experience is seldom the case these days.)

The fact that LC will be incrementally deployed alongside 1997, makes the
issue much more significant, IMHO.

Maybe folks from various vendors (including open source implementations)
could chime in on the availability of knobs for changing global (default)
behavior on 1997 and LC, and whether those traditionally have the same
default and/or are controlled by one knob (versus two)?

Brian

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Nov 2016 21:46:04 +0100

Hi Brian,

> could chime in on the availability of knobs for changing global (default)

Maybe we should move this thread to GROW maybe not, but since you started
the pool here I would add a question to indicate by any implementation that
if it drops an attribute (as it is not enabled to be sent over a session)
would it log it in syslog and if so with what error level. The worse
operationally are silent drops in any control plane.

r.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 7 Nov 2016 13:06:17 -0800

On Mon, Nov 7, 2016 at 12:25 PM, heasley <[email-masked]> wrote:

> > It might be the case that initial deployment could incorporate 16-bit
> ASNs in 32-bit fields, including private ASNs.
>

No, what I am saying is, it might be the case that the very first LCs seen
are "65501:3356:0" (which, in my hypothetical scenario, are transliterated
RFC1997 communities, understood by both AS2914 and AS49544)

The difference being:

   - RFC1997 propagation might be affected by some implementations of
   RFC1997 defaulting to "do not send" and router configurations relying on
   that default.
   - LC propagation, if not consistent with RFC1997 propagation, might
   result in the LC community going where the RFC1997 has not gone, and might
   result in changes to routing.

> > 20 years of  RFC1997. All with default off. 20 years of industry
> consolidation, staff turnover, undocumented implementations.
>

... which should not REQUIRE implementation/configuration changes
overnight, IMHO.

>
> > Assuming that no migration will occur, isn't helpful. Changing the
> default behavior across such migration is the risk.
> >

There are 3 ASNs involved, and two peering connections.
Does AS2 already do RFC1997?
Does AS1 send RFC1997 communities to AS2?
Is the reason AS1 isn't sending RFC1997, that AS3 is a 32-bit ASN?
Presumably AS2 doesn't send RFC1997 to AS3 either, for the same 32-bit ASN
reason.

I think the scenarios boil down to:

   - AS2 already does RFC1997, and does its upgrade with LC as part of the
   plan.
      - I would expect AS2 to monitor for LCs in their BGP updates before
      upgrading, and use an upgrade config that passes LCs.
   - AS2 does not do RFC1997, in which case expecting it to do LCs is not
   entirely reasonable on the part of AS1.
      - AS1 should discuss their expectations with AS2, and encourage them
      to do LCs AND RFC1997.

In other words, in neither case should the breakage be a surprise; it
either should not break, or should be expected to break.

I'm not advocating for breakage, obviously, and am a big advocate of both
RFC1997 and LC.

But, vendor code isn't best place to try to get communities propagated -
the contracts or peering agreements between ASNs is a much better place.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Mon, 7 Nov 2016 13:09:37 -0800

> operationally are silent drops in any control plane.
I would definitely be in favor of including that detail.

Also, I am not aware of whether attribute-sending is flagged in the
capabilities negotiation of an OPEN. That would, IMHO, be a better place to
signal attribute passing vs dropping, rather than on each UPDATE. What do
vendors think of that (or is it already done?)?

Brian

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Nov 2016 22:17:41 +0100

Hi Brian,

> Also, I am not aware of whether attribute-sending is flagged in the
capabilities
> negotiation of an OPEN. That would, IMHO, be a better place to signal
> attribute passing vs dropping, rather than on each UPDATE. What do

Large Community does not require capability negotiation hence its support
or not
will not be signaled in OPEN msg.

Assuming that you are proposing a new capability which would indicate if a
given
transitive attribute it to be propagated or not based on local
configuration that
while may be nice idea requires dynamic capabilities which as you very well
know is for number of years and after number of attempts to support it
nowhere.

Rgs,
R.

PS. Perhaps the right place for this would be Operational Message which
Rob, Dave
and myself proposed few years back but due to lack of support the idea died
in spite
of already being a WG supported draft ...

https://tools.ietf.org/html/draft-ietf-idr-operational-message-00

---

From: heasley <[email-masked]>
Date: Mon, 7 Nov 2016 22:54:17 +0000

>    result in changes to routing.

Everyone involved would have to actively change their policy to add that
LC and to take action on it.

And, why would an operator expend the effort to use 1997 communities in LCs
with an extra 0 field?  Leave the 1997s alone, add LCs specified to take
advantage of LCs (no over-loading, AS4) and stop taking action on and/or
marking routes with 1997s after some transition period.

> ... which should not REQUIRE implementation/configuration changes

it doesnt; LCs dont exist yet.

> Does AS2 already do RFC1997?

whatever - that's irrelevant in my PoV; 1997 & LC are not the same.

> Does AS1 send RFC1997 communities to AS2?

irrelevant.

> Is the reason AS1 isn't sending RFC1997, that AS3 is a 32-bit ASN?

maybe.  maybe AS3 never supported 1997.  maybe they have transitioned
away from 1997.  maybe its an "action" community with a "target" ASN
(AS3:prependonce:AS4).  or AS3 marks their routes with LC in some manner
that interests AS1, such the rt's region origin and AS4's path between two
regions is routinely congested.

> Presumably AS2 doesn't send RFC1997 to AS3 either, for the same 32-bit ASN

irrelevant.

fact is that it would work until AS2 upgrades, unless AS2 adds the config
to disable to default filtering - that is assuming that they are clueful
enough to do so.  that's an element of surprise.  vs. AS2 deciding that
they will start using LCs and discovering that their customers & transits
are already using them.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 8 Nov 2016 00:30:01 +0100

FWIW Heas is extremely right here.

> 1997 & LC are not the same.

Indeed and those who claim to say so in order to progress Large under the
cover of RFC1997 are just wrong (sorry).

We are defining a new world wide functionality in BGP and we should take
all what it takes to do it right.

If some folks want parity with RFC1997 Large should be 4:4 no more. It is
not 4:4 and it is a new attribute so whoever in their policy decides to use
new attribute to modify routes he/she better understands what are the
consequences.

While this may be taken as "distraction" or attempt to "derail" large I am
spending my private time on this list to make the best for BGP as protocol
realizing how hard it is to deploy new BGP extension worldwide.

And if so progressing large should be able to accommodate operators voice
captured in this document:

https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02

... and we are just few millimeters far from addressing 90% of those use
cases if we would not take a selfish view and turn large into 4:4:4:4.

With respect to all,
Robert.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 7 Nov 2016 17:33:50 -0800

> cover of RFC1997 are just wrong (sorry).

RFC1997 is 32 bits, used as "16-bit ASN" : "local".

LC is 96 bits, defined as "Global Administrator (aka 32-bit
ASN)":"local1":"local2".

LC provides more than 4:4 (which would have been the absolute minimum for
parity), and that extra 4 is appreciated and noted.

Upgrading RFC1997 to give parity back to it, would require "2:2:2" or
"2:2:4", and might have been useful 15 years ago, but whatever.
Having 4:4:4 available gives somewhere for RFC1997 to move to, and it can
do so without any collisions.
Global Administrator for 16-bit ASNs works just fine.

Concerning my earlier brief description and explanation of why things like
"65501:2914:0" might be among the first LC values seen:

I think understanding the rationale will be helpful in understanding,
generally, why all operators want/need is "32-bit ASNs and 32-bits of
non-overloaded space to design their own methodology".

So, here goes, again, this time with more words and hopefully clearer logic
and explanations.
(I should have known better than to try to do this using my smartphone.
Apologies for the earlier cryptic explanation.)

The following "table" shows the minimum level of support for doing "generic
communities" across 16-/32-bit ASN:

SRC \ DST  16-bit 32-bit
16-bit       1997   LC
32-bit     1997/LC* LC

The following table shows an "upgrade" path for 16-bit ASNs peering with
16-bit ASNs, who want parity with LC:

SRC \ DST  16-bit 32-bit
16-bit        LC    LC
32-bit        LC    LC

(* NB: RFC1997 was really only feasible for use between 16-bit ASNs, or
where the destination ASN's "action" target was a third-party 16-bit ASN.)

1997 and LC are not "the same". 1997 is the predecessor, and a subset, of
LC, in the same sense that 16 bit ASNs are the predecessors of, and a
subset of, 32-bit ASNs.

Here's what the operator community wants:

   - 32-bit ASNs and an extra 32 bits to play with.

Here's what the operator community wants the Global Administrator field to
mean:

   - The ASN of the entity defining the values and semantics for Local1 and
   Local2.

Here's what the operator wants the meanings of Local1 and Local2 to be:

   - <whatever the Global Administrator says>

This is not new functionality; it is parity with RFC1997, with more bits
(32 more bits, after expanding the second 16 bits of 1997 to 32 bits).

The semantics of RFC1997 were tortured to death, often by abusing the
private ASN values, which had the potential for causing communities
collisions.

It should be obvious that the availability of LC provides the means to end
this overloading, by providing enough room in Local1:Local2 to handle
any/all use cases that any 16-bit ASN requires.
(I say 16-bit ASN here, because, by definition, they are the only
globally-unique ASNs that were able to make use of RFC1997, without
squatting.)

Moving from RFC1997->LC give the potential to do more -- but to state the
obvious, does not require one to do more, or at least not in any specific
timeframe.

Suppose I am a 16-bit ASN, and I was using private ASNs in order to handle
use cases that exceeded the overall capacity of the lower 16-bits of
RFC1997.
So, I had two sets of RFC1997 communities:
MY_ASN:xxxx
yyyy:zzzz
(for many private ASNs yyyy)

The very first thing I would want to do is to get away from private-ASN
RFC1997 values, and I would deploy LC for those:
MY_ASN:yyyy:zzzz
I might also want to provide:
yyyy:zzzz:0
to ensure less-capable customers are able to make the right thing happen,
even if that LC is likely to collide with anyone else using it.

But now I am doing both RFC1997 and LC, which complicates my route
processing, and increases my maintenance.
So, I am going to migrate the rest of my RFC1997 communities, by some kind
of transliteration:
MY_ASN:0:xxxx
 or
MY_ASN:xxxx:0

Once, and only after, I have all my customers migrated, I can (and would)
decommission RFC1997 entirely (in my network, that is).

Now I can begin improving the capabilities offered, and migrate off of
overloaded xxxx's and yyyy:zzzz values.

HOWEVER, and this is really important, LC gives me the right NOT to do so,
or to do anything I want, no matter how foolish it is, so long I use
MY_ASN:Local1:Local2.

As an operator, I am not asking the IETF-IDR WG to do anything other than
give me the tools to do whatever I want, however I want.

This gives me independence from vendor lock-in, and the ability to switch
vendors without pain or delay.

This gives me the ability to operate a multi-vendor network, and to
interoperate with other operators' networks regardless of vendor.

This gives me the ability to acquire another operators' network, and
integrate it without significant problems

In this regard, this is precisely WHY the operator community only wants
parity with RFC1997.

The limited capabilities offered by vendors for fancy things was a FEATURE
of RFC1997, not a bug.

We had kind of hoped you (collective you, meaning all the vendors) had
learned this lesson over the last 20 years...

> all what it takes to do it right.

Give us MY_ASN:Local1:Local2.

That is what it takes to do it right. Anything else would be an abject
failure.

(We're fine if you insist on calling it Global Administrator:Local1:Local2.)

>
> If some folks want parity with RFC1997 Large should be 4:4 no more.
>

Wanting parity doesn't mean wanting _only_ parity. You can build a house
"to code" by building substantially better than "code". ("Code" means
minimum code.)

> It is not 4:4 and it is a new attribute so
>

(IMHO this whole "it is a new attribute" is a non sequitur...)

> whoever in their policy decides to use new attribute to modify routes
> he/she better understands what are the consequences.
>

I fail to see how that is any different than the implicit rules for RFC1997.

> captured in this document:

Irrelevant to LC...

"Have fun storming the castle!"

The massive -wide- thing fails to understand the fundamentals of operators'
reality:

   - Avoiding vendor lock-in
   - Avoiding vendor implementation delay
   - Avoiding vendor heterogenous version issues
   - Avoiding heterogenous-vendor networks issues
   - Speed to deployment of differentiating services based on RFC1997 (now
   LC) capabilities
   - One size never fits all
   - Customer size does not correlate to customers' importance to the
   Internet
      - For example, consider the relative number of routers for ICANN,
      IETF, ISOC, etc. versus a regional fast-food chain.
   - The IETF, in the vendor hardware/firmware space, operates so slowly
   that most features are already obsolete by the time they reach full
   standard. Sorry.
      - Large Communities has been the exception that proves the rule.

No offense intended towards anyone, just trying to make the operators'
position and reasoning as clear as possible, to those who aren't or haven't
been.

Sincerely,
Brian

---

From: Gert Doering <[email-masked]>
Date: Tue, 8 Nov 2016 11:59:39 +0100

HI,

> With respect to all,

I don't think it is.

Throwing wrenches into the process all the time is not respectful to those
that have waited for too-many years for something workable to show up,
and have clearly stated their support for -large already, and multiple
times.

Gert Doering
        -- NetMaster