Re: [Idr] Review of draft-ietf-large-community-06.txt

[Robert Raszuk <[e-mail]>]

​​

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


> Isn't it a subject for a customer-vendor meeting?


Honestly customer-vendor ​meetings are for new policy knobs. 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.


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

So if we want to make large nicely transitive I think it is now a good time
to add this to draft/rfc just to have a common agreed way on the expected
outcome in any implementation.

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 ?

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.

Thx,
r.