Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)

"Jakob Heitz (jheitz)" <> Mon, 07 November 2016 00:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BDFB1296B4 for <>; Sun, 6 Nov 2016 16:04:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.017
X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VtPFMOBdwReM for <>; Sun, 6 Nov 2016 16:04:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F05811296B3 for <>; Sun, 6 Nov 2016 16:04:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7086; q=dns/txt; s=iport; t=1478477059; x=1479686659; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GWPeDve+XAsUvzZHvMxi0laH6NzTDhbKZNyC8PeD2H8=; b=gQtCXbK3Izj/ffFyO4mTyk15somDaayYH0koPd3GoOT3uCsT5nZ8aaTc q9FBxa2Q7qfIiZkZ1kYG8aI3csOV3SLMg8jDT71e3j6AYVcg99NW3vsg2 +toZ5PbeYu/lXeAgwxxKeJfq0J8FSlirbkdGq+u12f2s316q+c1YNSt+X o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AQCixB9Y/5NdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM7AQEBAQEfWHyEK4kNpjiFGoIIHgEKhXsCggk/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGIBAQQBAQFrCxACAQg/BycLFBECBA4FFIhEDrJ0izsBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEXBYY+gX2CWId4gi8FlEeFYAGGNIoPkBCNKoQFAR43ehuCW4I0cod?= =?us-ascii?q?9AQEB?=
X-IronPort-AV: E=Sophos;i="5.31,603,1473120000"; d="scan'208,217";a="168088919"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2016 00:04:12 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id uA704CPn021313 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2016 00:04:12 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 6 Nov 2016 18:04:12 -0600
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Sun, 6 Nov 2016 18:04:11 -0600
From: "Jakob Heitz (jheitz)" <>
To: Robert Raszuk <>
Thread-Topic: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
Thread-Index: AQHSN546iba0WaPSYk6woE67Sz8aq6DLBUg9gAHyDwD//6OKGoAAZhSA//+kvhQ=
Date: Mon, 7 Nov 2016 00:04:11 +0000
Message-ID: <>
References: <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_C2C26B2F75A049FBB9474B957611A23Eciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [Idr] Vendor Defaults (was Re: 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: Mon, 07 Nov 2016 00:04:21 -0000

An example of unintended routing:
Both AS2914 and AS49544 use the private ASN 65501 to prepend one time.
If a route using 65501 in the community traverses both these ASes, then each AS will prepend, resulting in (likely unintended) double prepending.


On Nov 6, 2016, at 3:30 PM, Robert Raszuk <<>> wrote:

Hi Jakob,

Very fair and good summary !

One question: What is "unintended routing" ? Are you alluding to "churn" If so pls see my reply to previous post.

Just to reiterate ... I do recommend that whatever option gets more support it should be spelled out in the Large Community RFC such that all implementations can be consistent.


On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz) <<>> wrote:
The question:
Should Large Communities be transmitted across EBGP by default?

Note: there is a knob to change the default, so the discussion is how to act with the knob unconfigured.

Arguments to block:
1. Principle of least surprise: Do same as 1997.
2. Accidental leakage of internally used communities will cause unintended routing.

Arguments to pass:
1. Legacy code will pass it, because the attribute is transitive. Upgrade to LC aware code should do the same by default.
2. It is convenient to pass a community through your first level transit to fix a problem further upstream. A default block frustrates this effort.

The problem of accidental leakage is greater with 1997 communities, because many ISPs use private ASNs. This is as problem if a community intended for a distant ISP is interpreted by a near ISP when they use the same private ASN. This problem SHOULD disappear with Large Communities, because the need to use private ASNs no longer exists.

I would like to hear other arguments and gauge support for each case.


Idr mailing list<>