[Idr] community of the day - common header

Jeffrey Haas <jhaas@pfrc.org> Thu, 08 September 2016 21:45 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 109FA12B26E for <idr@ietfa.amsl.com>; Thu, 8 Sep 2016 14:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.41
X-Spam-Level:
X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 kpIZ9ORZ-bdC for <idr@ietfa.amsl.com>; Thu, 8 Sep 2016 14:45:40 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 15330127058 for <idr@ietf.org>; Thu, 8 Sep 2016 14:39:27 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 914321E331; Thu, 8 Sep 2016 17:40:31 -0400 (EDT)
Date: Thu, 08 Sep 2016 17:40:31 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: idr@ietf.org
Message-ID: <20160908214031.GA23544@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/HdbTc0m6MuquHjOmo62A6PR9xsU>
Subject: [Idr] community of the day - common header
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: Thu, 08 Sep 2016 21:45:41 -0000

[A portion of this conversation was held not only in the halls at the recent
Berlin IETF, but at the IDR mic.]

I'm generally agnostic about the idea of the encoding of a 4:4 style
community.  The fact that the 4:4 encoding in the wide-comms draft was able
to shift from TLV (atom) based to flattened as seen in -03 should make it
obvious that the wide comms draft authors also sees that particular point
agnosticly.

The one point that I did push on heavily in earlier discussions is that
future community (route coloring) mechanisms should stop burning path
attributes for each new type.  I strongly believe that a new common header
for future community mechanisms is needed:

- We shouldn't be burning path attributes for it.  While the code space for
  it isn't being exhausted fast, it means the only way to discard
  unparseable attributes (implementation doesn't support) is a general path
  attribute filtering mechanism.  Such filtering mechanisms are hazardous to
  the incremental deployment of new BGP features.
- By using a common header, undesireable classes of communities can be
  filtered simply by type.  This can be done without any knowledge of the
  format.

To offer an example of why such behaviors are desirable, early deployments
of extended communities caused unfortunate effects far away from the
attaching router because intermediate routers didn't understand the
attributes.  This is a fundamental deployment issue of optional-transitive
unknown attributes.

I'm not particularly fond of the theater that has gone into this discussion
- and good will has been burned by that theater.  But regardless of the
proposal to implement 4:4, 4:4:4, N:4 ipv6:4 or whatever we invent next
month, let's nip this bit of deployment madness.

A proposal for a common header is contained in section 3.1 of the wide
communities draft.

-- Jeff