Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Randy Bush <randy@psg.com> Tue, 08 September 2020 20:03 UTC

Return-Path: <randy@psg.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 2C5E43A10C1; Tue, 8 Sep 2020 13:03:47 -0700 (PDT)
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, SPF_HELO_NONE=0.001, 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 e_D7fpD4oIGL; Tue, 8 Sep 2020 13:03:46 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E677B3A10BD; Tue, 8 Sep 2020 13:03:45 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1kFjqB-0001fH-KO; Tue, 08 Sep 2020 20:03:43 +0000
Date: Tue, 08 Sep 2020 13:03:43 -0700
Message-ID: <m2d02whw80.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: Interminable Discussion Room <idr@ietf.org>
In-Reply-To: <081E5E98-8D7B-452E-8517-EECBE72E3D7F@juniper.net>
References: <081E5E98-8D7B-452E-8517-EECBE72E3D7F@juniper.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LtZIgl3a-caj9vjxbRaJnY8Vxyk>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 08 Sep 2020 20:03:47 -0000

i think we have multiple flavors of signaling.  i am not sure there is a
crisp taxonomy, but some of the spaces could be describes as

  o hard core routing data, bgp classic

  o state signals, please chill out i am gonna sleep/restart/die

  o conditions, the circuit's bandwidth, color, delay, flavor

  o policies, prefix limits, code flavor, ...

and we're trying to squeeze them all into some funny containers, bgp
tlvs, capabilities, bgp-ls, ...; most of which were designed for other
purposes.

as you point out, draft-ietf-idr-operational-message is another
container which kinda tried to hold some of these.  it could certainly
deal with the proposal at hand.

but it sure would be nice if we had a little archetectural structure
and regularity here.

randy