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

martijnschmidt@i3d.net Mon, 07 November 2016 01:07 UTC

Return-Path: <martijnschmidt@i3d.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 2195B129A62 for <idr@ietfa.amsl.com>; Sun, 6 Nov 2016 17:07:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 i9MTVLFm_Ubt for <idr@ietfa.amsl.com>; Sun, 6 Nov 2016 17:07:01 -0800 (PST)
Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F3C129A5F for <idr@ietf.org>; Sun, 6 Nov 2016 17:07:00 -0800 (PST)
X-Footer: aTNkLm5s
Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 7 Nov 2016 02:06:52 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <C2C26B2F-75A0-49FB-B947-4B957611A23E@cisco.com>
References: <CAH1iCiq6jNtnkta0Bt952EQ9zOKSGt=_cCySsT5XuOKuHYO2nQ@mail.gmail.com> <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com>, <CA+b+ERm5VVz520OhgXYTFOt9_M6_=MHLE9M-=1T+wnfw7RY83Q@mail.gmail.com> <C2C26B2F-75A0-49FB-B947-4B957611A23E@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----74QWZWGQKBXHPV3KF7DLGSP2YFIOEX"
Content-Transfer-Encoding: 8bit
From: martijnschmidt@i3d.net
Date: Mon, 07 Nov 2016 02:06:38 +0100
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, Robert Raszuk <robert@raszuk.net>
Message-ID: <0EB44887-7C06-4598-8911-D8DBA8532D53@i3d.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/H_XJ6uFN2Vn_vdovrTCdxtYtNAE>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] Vendor Defaults (was Re: 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: Mon, 07 Nov 2016 01:07:04 -0000

Worse still, if a certain ISP is dualhomed one could make the prefix partially unreachable for a significant portion of the Internet. Say that AS49544 would be multihomed between AS2914 + AS3356 and a customer of the first network sets 65500:3356, then both networks would not export to AS3356. Because neither AS2914 nor AS3356 buys transit, the result would be that singlehomed customers of AS3356 don't receive the prefix at all. Fortunately, that problem goes away with Large Communities thanks to the Global Administrator field. Jakob, I think this addresses your 2nd "argument to block". 

Continuing my argument, today's routers (at least Brocade) have the following default behaviour when handling RFC1997 communities: accept everything, but don't pass it on to your neighbors, neither iBGP nor eBGP. Of course that default doesn't work for us since the former would pose a security risk, and the latter would effectively break any community system. Since any neighbor can unilaterally enable send-community to begin transmitting RFC1997 communities, an ISP writing any kind of routing policy involving BGP communities must already decide for themselves how they're going to handle the receipt of a community tag from their neighbors (ignore, sanitize, pass through, etc). On the other hand, if an ISP doesn't use BGP communities in their routing policy at all the attribute means nothing and can (should?) be passed on transparently. Especially in case of Large Communities where legacy code will already behave that way. 

The takeaway from all this is that it's harmless to send communities by default. I think it's beneficial to receive as much information from your neighbors as possible. It makes debugging easier and could allow for receiving ISPs to optimise routing policy. 

Best regards, 
Martijn Schmidt 

On 7 November 2016 01:04:11 CET, "Jakob Heitz (jheitz)" <jheitz@cisco.com> wrote:
>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.
>https://onestep.net/communities/as2914/
>https://onestep.net/communities/as49544/
>
>Thanks,
>Jakob.
>
>
>On Nov 6, 2016, at 3:30 PM, Robert Raszuk
><robert@raszuk.net<mailto:robert@raszuk.net>> 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.
>
>Best,
>Robert
>
>
>On Mon, Nov 7, 2016 at 12:25 AM, Jakob Heitz (jheitz)
><jheitz@cisco.com<mailto:jheitz@cisco.com>> 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.
>
>Thanks,
>Jakob.
>
>_______________________________________________
>Idr mailing list
>Idr@ietf.org<mailto:Idr@ietf.org>
>https://www.ietf.org/mailman/listinfo/idr
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Idr mailing list
>Idr@ietf.org
>https://www.ietf.org/mailman/listinfo/idr

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.