[Idr] Re: Text representation of BGP Path Attributes (mostly Extended Communities)

Maria Matejka <maria.matejka@nic.cz> Mon, 01 June 2026 09:18 UTC

Return-Path: <maria.matejka@nic.cz>
X-Original-To: idr@mail2.ietf.org
Delivered-To: idr@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 35374F8954E6 for <idr@mail2.ietf.org>; Mon, 1 Jun 2026 02:18:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1780305526; bh=/aZ7qM3q2G/WzyOxzrccPocGP9TtSy1qOHIEjvvcZak=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=WEoxDZ/vxqtCxSCcffmxIaZ+NXpgPKmtXOM2MsSHTc6t1zUGz8mFekciLcgzHUjCs AEtKbrdIUfT7vzgxwoo/a2qhPvsNwcqfVRwNMeoZg3EqiS8IUtPINZCnQ9E4pZ7dEx /aCmUxvgeqMMzOPeIIOOYqXNL4qUaJ4CmRTMctBQ=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -7.1
X-Spam-Level:
X-Spam-Status: No, score=-7.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNfWOn40V2Rb for <idr@mail2.ietf.org>; Mon, 1 Jun 2026 02:18:44 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 5DE8EF8954DF for <idr@ietf.org>; Mon, 1 Jun 2026 02:18:44 -0700 (PDT)
Received: from struhadlo.private.jmq.cz (unknown [IPv6:2001:1488:fffe:6:b094:83ff:fecd:1f52]) by mail.nic.cz (Postfix) with ESMTPSA id 7C3AA1C05FA; Mon, 1 Jun 2026 11:18:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nic.cz; s=default; t=1780305522; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VNATnPSlBCbDvElPNpVLGQ14AC/uKnvvQA3iIm0anWc=; b=LBev657RT4/UsfPUfBmKPnE2AOL2kF1iGv93V1o3LzFfjemB18H9XoXoXXTujfBjTzEfjd XpWDCM0Gtwlv9ng8SqBc6cKQFEhrcBbOcYGajpnp4jKkXJ36BQAPdh2TLgRtVlWDZrYCSK fK3IfGig4jBSepDdeoECvazUugQLr7o=
Authentication-Results: mail.nic.cz; auth=pass smtp.auth=maria.matejka@nic.cz smtp.mailfrom=maria.matejka@nic.cz
Date: Mon, 01 Jun 2026 11:18:41 +0200
From: Maria Matejka <maria.matejka@nic.cz>
To: Donatas Abraitis <donatas.abraitis@gmail.com>
Message-ID: <ah1OcQ6y4FU3sxAB@struhadlo.private.jmq.cz>
References: <7AC732D5-4F4C-4DA7-A58E-136AF4B30EA1@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1Hqq289zEMUrSXwB"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7AC732D5-4F4C-4DA7-A58E-136AF4B30EA1@gmail.com>
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-0.10 / 16.00]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FUZZY_RATELIMITED(0.00)[rspamd.com]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; ASN(0.00)[asn:25192, ipnet:2001:1488::/32, country:CZ]; WHITELISTED_IP(0.00)[2001:1488:fffe:6:b094:83ff:fecd:1f52]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; DKIM_SIGNED(0.00)[nic.cz:s=default]; FROM_HAS_DN(0.00)[]; ALIAS_RESOLVED(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; LOCAL_OUTBOUND(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]
X-Rspamd-Server: mail
X-Rspamd-Queue-Id: 7C3AA1C05FA
X-Spamd-Bar: /
X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: WHITELISTED_IP
Message-ID-Hash: PI5GCIOIB3VXNTLJ4XSFVL3OPEJDFGDO
X-Message-ID-Hash: PI5GCIOIB3VXNTLJ4XSFVL3OPEJDFGDO
X-MailFrom: maria.matejka@nic.cz
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: idr@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Idr] Re: Text representation of BGP Path Attributes (mostly Extended Communities)
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/yDjsP6_z1HN2IoI6F5IP80W_1J8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Hello Donatas!

On Sun, May 31, 2026 at 08:17:36PM +0300, Donatas Abraitis wrote:
> Hi,
> 
> > https://datatracker.ietf.org/doc/draft-marenamat-idr-bgp-attribute-formatting/
> 
> good initiative.

Thanks, I take this as "100 please continue".

> For AS_PATH attribute we should perhaps notice/say that AS sets are out of scope for this document?

Indeed, they are already deprecated by RFC 9774 and even more hated by
ASPA. I don't wanna touch them even by an 8 foot pole. But we could add
an explicit note about the deprecation there.

> As I understand this is very early version of this draft and does not
> include the rest of the attributes, e.g.: large communities, role,
> etc.?

Yup, very much unfinished, I prefer consulting the overall direction
on a sample before doing the whole thing. It's quite time-consuming to
research all the stuff one needs to cover, even with some help of LLMs.

Roles are easy, that's just an enum with names easily defined in the
YANG model. The same with the Origin attribute.

The real problem are actually mostly EC which one probably doesn't wanna
send through the XML/JSON as "0x0202fffe0408aa5f" but rather
"rt:65534:67676767". And with CBOR, one needs to know how to convert the
binary representation to the textual one.

We can, alternatively, just send hex or uint64 through NETCONF/RESTCONF,
but that's not easily human-readable and one would need a convertor
on the client side anyway for interpretation.

> > In addition to that, it is RECOMMENDED to format well-known communities as their string name.
> 
> In FRRouting, we have something called "community-alias", where the
> operator can override the value to be displayed in show commands. So
> let's say we have a community 65001:1, and a community-alias ca1
> mapped to this 65001:1. Then in every show command we show ca1 instead
> of numeric values. Wouldn't this be something similar?

What about adding an overall recommendation like

    If the implementation supports assigning unique names to numerical
    values, it is RECOMMENDED to display these values as their names.

But actually I'm targeting this list:
https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml

It looks like I failed to put there some better reference than just
renaming of STANDBY_PE. Gonna fix that.

Thanks!

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.