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

Robert Raszuk <robert@raszuk.net> Sat, 05 November 2016 18:57 UTC

Return-Path: <rraszuk@gmail.com>
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 E84AF12997B for <idr@ietfa.amsl.com>; Sat, 5 Nov 2016 11:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jYAkfMrhYCbr for <idr@ietfa.amsl.com>; Sat, 5 Nov 2016 11:57:31 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E015129973 for <idr@ietf.org>; Sat, 5 Nov 2016 11:57:31 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id f82so48287228wmf.1 for <idr@ietf.org>; Sat, 05 Nov 2016 11:57:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xuBO8Qxb69//6djAE6yhnCSMxbJl2z1qwZKUeyzDP/A=; b=SLG3X3BxnsyK73SZJR6+nV8AxJGKWJCyaUMkiU7+s605zOXyMj35EV6L2R9Mgsmzhk f89W02iN4Rmr7ikYbe+scnWtYKExP8oN4B4uNHj5x3NrmMNcVZ+EjbPmHTnszuH8xpeY ZhdpAuGB4cksdjQ+57s6N2+EWmlppTkkZKvhh86ByRuNpigfaB3SZG4wdbxcqs5R5SqM TDcbzAQZWrnAZyj7DudiyDZLjtGEUQ74ioO1YsYJ9jz0ffTuA6oQctkj+3vKVZdFOpYC ajRG03+DGPHnpxCU3sOXZXScSxk9NVHx+V5XzMJqbMyoT0n/nsnux/qOhDx7RACXetMn +KHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xuBO8Qxb69//6djAE6yhnCSMxbJl2z1qwZKUeyzDP/A=; b=Eontd22UCkVD+tJz3o1MR+GWHgqwS7/pwHCd1HHZkhG7oxeWe3QXpjQM+oxqN+sAUp uhda2q4e7JKYIPm9aBITF7mvH1+pS6loeOdR9ZyfquR9n+s6U5HHDujPJhKICi9V9iGl R0bzxuwZr4OXWw2HEg4s3fUQ353RA3kij4jvoNDa1JS4OeO3elIjZTY0x4E4uwsEFvSr 3+eGsLAwOPB8rV3QojJWtuzy4qF4J9+D4xvltMo6AcwFF4WBVCoQl1A9MoqhsRXtOCsC NyzGsfG90KxGtrbSdrTUVCI0516h++z5aO8r5VLMRAXN8SuK6364/O2s0sv50hSDdwVG FAQQ==
X-Gm-Message-State: ABUngvcU0H6HtOWrSDIvqnjrB3oJKmSrYM03fzgGY1N8QtumL82JfY7b1T+gG6O3B3gbBgi4Ji+rs1n114H00Q==
X-Received: by 10.194.187.103 with SMTP id fr7mr9378846wjc.99.1478372249756; Sat, 05 Nov 2016 11:57:29 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sat, 5 Nov 2016 11:57:28 -0700 (PDT)
In-Reply-To: <20161105183517.GI98782@shrubbery.net>
References: <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <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>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 5 Nov 2016 19:57:28 +0100
X-Google-Sender-Auth: luJFZ4Xc4NBQPE6on9g4eOM3sv8
Message-ID: <CA+b+ERnCvpFJadZsSGussdsh4SzJEZrF+1WihX=yw9BGBpnqug@mail.gmail.com>
To: heasley <heas@shrubbery.net>
Content-Type: multipart/alternative; boundary=047d7bd6bc9ccaeb5e0540925cb5
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NvT3i_T9gQZolnnRtuJruRG_Wj0>
Cc: "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: Sat, 05 Nov 2016 18:57:33 -0000

​​

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