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

[heasley <[e-mail]>]

Sat, Nov 05, 2016 at 07:57:28PM +0100, Robert Raszuk:
> > 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.

i'd be shocked if operators dont remember a few that they've been requesting
for 2 decades (sorry to pick on cisco)

	no ip proxy-arp
	no ip redirects
	no ip directed-broadcast

iirc, all 3 are the default on ios-xr.

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

shouldnt you clarify in 4271 - that which is transitive is transitive (by
default), recognized or not.

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

not imo; doesnt apply to 1997 either - not in year 1997 either, again - imo.