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

heasley <heas@shrubbery.net> Sun, 06 November 2016 05:16 UTC

Return-Path: <heas@shrubbery.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCFB12969B for <idr@ietfa.amsl.com>; Sat, 5 Nov 2016 22:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o05oYVv05LEd for <idr@ietfa.amsl.com>; Sat, 5 Nov 2016 22:16:48 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2EE129690 for <idr@ietf.org>; Sat, 5 Nov 2016 22:16:48 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 8580E7A277; Sun, 6 Nov 2016 05:16:47 +0000 (UTC)
Date: Sun, 06 Nov 2016 05:16:47 +0000
From: heasley <heas@shrubbery.net>
To: Robert Raszuk <robert@raszuk.net>
Message-ID: <20161106051647.GD18931@shrubbery.net>
References: <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan> <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com> <20161105103526.GM952@Vurt.local> <CA+b+ERnRJ5Ko9XXF+_wxRUeWVGV5NuwmewSo0nGg-cCyBQNx2g@mail.gmail.com> <20161105174229.GG98782@shrubbery.net> <CA+b+ER=jvwh02+MauOqaGt=S-65CWVEDeg_PwUxm2qx6OURdOQ@mail.gmail.com> <20161105183517.GI98782@shrubbery.net> <CA+b+ERnCvpFJadZsSGussdsh4SzJEZrF+1WihX=yw9BGBpnqug@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+b+ERnCvpFJadZsSGussdsh4SzJEZrF+1WihX=yw9BGBpnqug@mail.gmail.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KD6xsWhu5SCH4ZirNQoIsGSK-6M>
Cc: heasley <heas@shrubbery.net>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Nov 2016 05:16:49 -0000

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.