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

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 07 November 2016 03:46 UTC

Return-Path: <brian.peter.dickson@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 74E77129B55 for <idr@ietfa.amsl.com>; Sun, 6 Nov 2016 19:46:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 s70hJhferf2S for <idr@ietfa.amsl.com>; Sun, 6 Nov 2016 19:46:13 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 32D7E129B4F for <idr@ietf.org>; Sun, 6 Nov 2016 19:46:13 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id d2so84122384pfd.0 for <idr@ietf.org>; Sun, 06 Nov 2016 19:46:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7C2yq9zZlc5OQIyPQdeI6Nvz1LxQDoRaWwHnwhlD1Yk=; b=MEMch5xzbWQB0Qn2BlX408oGI7uGFAlRPTGyS1xf5RL9WiQ9GoRrOcfAreacjDcKDF Ny/zDTvMCy/MziWrX3lZS7ZNie5PT2NfK5Q4e9O4ZBq7Jpb4GoMioxce/wS/pcBC1s4d DOEGqIBL64nr8s/5hJvwZMJdjKOIFT4vBS/FgAgpW4Eepu3D8eDARpxMh25LYalZyR4l u9YdLLBZQQw/ZNOHJbwmcJr5zGqCP6BrKgx/TPJhKsVm1+MEv3ug7eTYHmi3HoI7l+24 eqpnQhahd8oT31aCbgHWUXENaLa4KNnBSIiiVxQkGg+VIri6V5IpVS7lFP9XAV8XoqTx Xwgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7C2yq9zZlc5OQIyPQdeI6Nvz1LxQDoRaWwHnwhlD1Yk=; b=NyaCn0mGRRAaB4M/erGYE+dhkArY50OWll4YfcWmQX9lwCS5YCMiuHTShSucwdonYP OiQ+wSMuE1jFsrNbMQYrZrBK13QJq3buGirXBDkZlr4Oge61VQ3U1ctyqUBUpgBG22ee FJVYt0fkMv2O/PVVSMIETS45CEgt7TammtCRTAXxPwXExkp6KYdRbFnwPPgrKN6LVYFn v2JNDsYhXo6/3ZrgB59BdqAGNPMpHB2ZYTPewgETOf+wUXsrPfZOrLTdHb87GSu0BOkg jP/KkFlxealZX+346wsrHubhpPOeip1q0ZBAxW2ID7Mpin2hZnK8uoBMhLCnRLOJzLRf c5Lw==
X-Gm-Message-State: ABUngveOAaNbj6JmSicU7EBdTGkBB/BQZQo0aKQXUvyv3NO5qwGQBMCXkRt06H/B9e9P6g==
X-Received: by 10.98.55.67 with SMTP id e64mr9768427pfa.80.1478490372699; Sun, 06 Nov 2016 19:46:12 -0800 (PST)
Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id p68sm18381819pfd.11.2016.11.06.19.46.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Nov 2016 19:46:11 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-D39CB469-0A0C-4F2E-9662-CAFB3226645A
Mime-Version: 1.0 (1.0)
From: Brian Dickson <brian.peter.dickson@gmail.com>
X-Mailer: iPhone Mail (14B100)
In-Reply-To: <CA+b+ERkieHXpXQxjGnU+dGAz2nbNzWb6DxHG6vB7X5bp9VD3+Q@mail.gmail.com>
Date: Sun, 6 Nov 2016 19:46:10 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.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> <CA+b+ERkieHXpXQxjGnU+dGAz2nbNzWb6DxHG6vB7X5bp9VD3+Q@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/j7wPo2ff4awjWO1d88AmBFhYIjU>
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 03:46:15 -0000


Sent from my iPhone

> On Nov 6, 2016, at 4:12 PM, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
> Isn't the main motivation of LC to avoid overloading the target ASN with private ASN values to embed the action ? 

It may be the motivation for having 3 x 32-bits, but the MAIN motivation is support for 32-bit ASNs.

It might be the case that initial deployment could incorporate 16-bit ASNs in 32-bit fields, including private ASNs.

Those using 1997 might want to migrate to large-only, rather than continue supporting both large and 1997. That migration could start with accepting both (1997 and large-encoded 1997 of 0000ASN16:0000ASN16:0), having customers add or switch to large, and then dropping 1997 support.

So, let's consider the implications of having large be sent by default, vs not.

When customers add the large communities, they will go everywhere if they don't filter, i.e. if they aren't aware of the need to filter large communities.

So, why would that migration be expected or considered reasonable, if the long term goal of LC is GA:target:action? Because it is the simplest, cleanest, and safest path. 

Having 1997 and large simultaneously used means possible corner cases or inconsistencies can occur. 

Once the 1997 semantics are transliterated, only then can real LC be implemented on the receiving side.

That would involve two windows of overlap: 1997 to transliterated; and transliterated to "real" LC.

And in both windows, the 1997-semantics large communities can collide, just like the conflicting cases Jakob listed.

That issue is a non-issue if the default is "off".

> Besides both are applicable to their directly connected customers so really regardless of the default those should be dropped by policy after execution/application. 

I believe this is called "blaming the victim".

There is no easy way to tell how many such conflicts would be exposed by default "on".

20 years of  RFC1997. All with default off. 20 years of industry consolidation, staff turnover, undocumented implementations. 

Assuming that no migration will occur, isn't helpful. Changing the default behavior across such migration is the risk.

Having the same behavior for large guarantees zero incremental risk, which is why I am advocating for it.

Brian


>> On Mon, Nov 7, 2016 at 1:04 AM, 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> 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> 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
>>>> https://www.ietf.org/mailman/listinfo/idr
>>> 
>> 
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr