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

Robert Raszuk <> Sat, 05 November 2016 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E84AF12997B for <>; Sat, 5 Nov 2016 11:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jYAkfMrhYCbr for <>; Sat, 5 Nov 2016 11:57:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E015129973 for <>; Sat, 5 Nov 2016 11:57:31 -0700 (PDT)
Received: by with SMTP id f82so48287228wmf.1 for <>; Sat, 05 Nov 2016 11:57:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id fr7mr9378846wjc.99.1478372249756; Sat, 05 Nov 2016 11:57:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 5 Nov 2016 11:57:28 -0700 (PDT)
In-Reply-To: <>
References: <20161104201631.GA35942@Vurt.lan> <> <20161104221030.GD37681@Vurt.lan> <> <20161104230536.GJ37681@Vurt.lan> <> <20161105103526.GM952@Vurt.local> <> <> <> <>
From: Robert Raszuk <>
Date: Sat, 5 Nov 2016 19:57:28 +0100
X-Google-Sender-Auth: luJFZ4Xc4NBQPE6on9g4eOM3sv8
Message-ID: <>
To: heasley <>
Content-Type: multipart/alternative; boundary=047d7bd6bc9ccaeb5e0540925cb5
Archived-At: <>
Cc: "" <>
Subject: Re: [Idr] Review of draft-ietf-large-community-06.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.