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

Brian Dickson <> Mon, 07 November 2016 21:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A070E12956F for <>; Mon, 7 Nov 2016 13:06:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Q-nTqFoBU8E for <>; Mon, 7 Nov 2016 13:06:20 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C669D129431 for <>; Mon, 7 Nov 2016 13:06:19 -0800 (PST)
Received: by with SMTP id a197so207814294wmd.0 for <>; Mon, 07 Nov 2016 13:06:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id d3mr6979989wjx.96.1478552778336; Mon, 07 Nov 2016 13:06:18 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 7 Nov 2016 13:06:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Brian Dickson <>
Date: Mon, 7 Nov 2016 13:06:17 -0800
Message-ID: <>
To: heasley <>
Content-Type: multipart/alternative; boundary=047d7bfd001022902b0540bc6536
Archived-At: <>
Cc: "" <>, Robert Raszuk <>
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 21:06:21 -0000

On Mon, Nov 7, 2016 at 12:25 PM, heasley <> wrote:

> Sun, Nov 06, 2016 at 07:46:10PM -0800, Brian Dickson:
> > > On Nov 6, 2016, at 4:12 PM, Robert Raszuk <> 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

I think the scenarios boil down to:

   - AS2 already does RFC1997, and does its upgrade with LC as part of the
      - 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.