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 21:06 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 A070E12956F for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 13:06:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, 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 7Q-nTqFoBU8E for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 13:06:20 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 C669D129431 for <idr@ietf.org>; Mon, 7 Nov 2016 13:06:19 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id a197so207814294wmd.0 for <idr@ietf.org>; Mon, 07 Nov 2016 13:06:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CJ7kYXYR9GA65XcDL9s8urGC97BTOzCsAP5RG6PBrYw=; b=gd36IJDz4wJru4O0EkYNrSsQrcK6FY/clOXyCjqlNX1tOEZpx7NSjuCuFBBGgsqhVr yuC/j5MdBTinsIuQyDL/ulNabRzjcA5iTAnPgted2nR42+paqVddDaE0DKfxJ81BFIPd 73vOzGLVi45ln2PMNWkNf/o6AQwtZOrH3hsYZVzDmN7NmSSAAIEYHnCRNk+qld6QoR4/ syupyU2eA1zVJWWUDMnOMB7l4E7qDKbfQwHlkSFvjnFJa1V8lDYvM1GEbbzTqi1um8NC E2A2MIZGBpXf7HVdPC5eYVl4HecwuGNEAyOfeUeyZWcJ7HbFZt0bTqSs5eVNtHwdQSK9 f0DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CJ7kYXYR9GA65XcDL9s8urGC97BTOzCsAP5RG6PBrYw=; b=bV16DNGBmBQRL4vyTIaIii0CvtkBQYR4a+vxoNhTZLnpjlY+fsxd12tcW1qnlMu07A 1hvKzXp5JId1doW2LLEbuDeNVW4189jk/IWwV7UYty0x58K9qCJQ/fvFg51C0lJoU+5f /0Ih5GMoslEIfthJ8GyJS3GB92rpJAWUi6cDzmzBzO3r8zLYGCaEqqjeaNtwaQ3mWDEd dIlw1fCbnbV0RUU09sRmsyXcllxsmDi2gPcDjoowI2ppCx6jtVmWX/KAHKIOSdv7obJ5 Ybkisg0/xMyLQzTg63wOgEjv2HbJlraPGj3slyTaTArJ7CKPkReYEMejBeaItqSJC8wj r27w==
X-Gm-Message-State: ABUngvd+JRO4/3+M2tKxIRZ2xJtuPC2Y/IpLwqHIQTjQEWGmeuvtPghmgqcbUKONcNPDntVozmxaGudpDZl/wA==
X-Received: by 10.194.78.195 with SMTP id d3mr6979989wjx.96.1478552778336; Mon, 07 Nov 2016 13:06:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.197.132 with HTTP; Mon, 7 Nov 2016 13:06:17 -0800 (PST)
In-Reply-To: <20161107202554.GI62252@shrubbery.net>
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> <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.com> <20161107202554.GI62252@shrubbery.net>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 7 Nov 2016 13:06:17 -0800
Message-ID: <CAH1iCipFL3BGKRzz+LfbkOAPePsGBLdRo0HBCjTFwnMC1+-+eA@mail.gmail.com>
To: heasley <heas@shrubbery.net>
Content-Type: multipart/alternative; boundary=047d7bfd001022902b0540bc6536
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LoBdCIms979dQVPK-IguwhfH5Uo>
Cc: "idr@ietf.org" <idr@ietf.org>, Robert Raszuk <robert@raszuk.net>
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 21:06:21 -0000

On Mon, Nov 7, 2016 at 12:25 PM, heasley <heas@shrubbery.net> wrote:

> Sun, Nov 06, 2016 at 07:46:10PM -0800, Brian Dickson:
> > > On Nov 6, 2016, at 4:12 PM, Robert Raszuk <robert@raszuk.net> wrote:
>
>
> > It might be the case that initial deployment could incorporate 16-bit
> ASNs in 32-bit fields, including private ASNs.
>
> What?  is there a case where a 16bit ASN doesnt fit in 32bits?
>

No, what I am saying is, it might be the case that the very first LCs seen
are "65501:3356:0" (which, in my hypothetical scenario, are transliterated
RFC1997 communities, understood by both AS2914 and AS49544)

The difference being:

   - RFC1997 propagation might be affected by some implementations of
   RFC1997 defaulting to "do not send" and router configurations relying on
   that default.
   - LC propagation, if not consistent with RFC1997 propagation, might
   result in the LC community going where the RFC1997 has not gone, and might
   result in changes to routing.



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

... which should not REQUIRE implementation/configuration changes
overnight, IMHO.

>
> > 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.
>
> given a BGP topology of AS1 - AS2 - AS3, where AS1 & 3 recognize LCs and
> AS1 sends LC 3:n:n to affect their local-pref (or whatever), this will
> potentially break when AS2 updates to an o/s that recognizes LCs.
> surprise!
>

There are 3 ASNs involved, and two peering connections.
Does AS2 already do RFC1997?
Does AS1 send RFC1997 communities to AS2?
Is the reason AS1 isn't sending RFC1997, that AS3 is a 32-bit ASN?
Presumably AS2 doesn't send RFC1997 to AS3 either, for the same 32-bit ASN
reason.

I think the scenarios boil down to:

   - AS2 already does RFC1997, and does its upgrade with LC as part of the
   plan.
      - I would expect AS2 to monitor for LCs in their BGP updates before
      upgrading, and use an upgrade config that passes LCs.
   - AS2 does not do RFC1997, in which case expecting it to do LCs is not
   entirely reasonable on the part of AS1.
      - AS1 should discuss their expectations with AS2, and encourage them
      to do LCs AND RFC1997.

In other words, in neither case should the breakage be a surprise; it
either should not break, or should be expected to break.

I'm not advocating for breakage, obviously, and am a big advocate of both
RFC1997 and LC.

But, vendor code isn't best place to try to get communities propagated -
the contracts or peering agreements between ASNs is a much better place.

Brian