[Idr] Re: [Core] draft-haas-idr-bgp-attribute-escape-04 - WG Adoption call (6/2 to 6/16/2026).

[Robert Raszuk <[e-mail]>]

Hi Jeff,

Yes while my first idea was to indeed import such lists to the routers
later I realized that it may be easier said then done due to zoo of
reasons.

So if you ask me today I would consider such list to be published by IETF,
IANA, *NOG as sort of advisory to operators building their BGP policies
within given's vendor configuration file.

And yes I've just build both exclude and scope lists.

You are absolutely correct that deprecated could be a separate list on its
own.

Excluded attributes in AFI/SAFIs that should never show up could be also
separate from Excluded in general over the EBGP boundary.

Otherwise operators may need to compile such a list on their own .. sure
with everywhere present AI these days it is an easy task, but the
thought is that if we publish such a list it will be at least reviewed by a
few humans :)

Cheers,
R.


On Wed, Jun 10, 2026 at 7:24 PM Jeffrey Haas <[e-mail]> wrote:

> Robert,
>
>
> On Jun 7, 2026, at 13:32, Robert Raszuk <[e-mail]> wrote:
>
> Hi Jeff,
>
> I think documenting the things we know are currently problematic is a
>> reasonable item for the appendix.
>>
>
> If this is of any help I created an interactive html doc (attached below)
> which lists BGP Attributes which should not be present in a given AFI/SAFI
> (Selectable in top-left corner).
>
> Perhaps you may consider at least recommending that when seen such
> attribute type in specific AFI/SAFIs a syslog warning should be generated.
>
>
> Thanks for the example.  Please note that my comments here are general
> discussion points and not intended to be a specific criticism of the
> example's contents.
>
> One of the useful things for the framing of this example is that many
> types of things we want to protect against end up being exclude lists.
> Working from excludes rather than explicit permits is helpful in not
> encouraging people to firewall all of BGP that they don't want and thus
> harming incremental deployment of new features.
>
> The second useful thing is the attempt to be AFI/SAFI specific.
>
> The other things that are important to discuss before text is written in
> the draft are:
>
> What do we do when the entry in such a registry is wrong?  As an example,
> the IPv6-specific extended community is restrictively scoped and probably
> shouldn't be.  Had we put this into the document and implementations
> deploying it, we've set the stage for issues in incrementally updating who
> knows how much of the Internet.  The real point here is RFC text that is
> utterly safe may be okay, but that we need to figure out how the filters
> should be "agile".
>
> This suggests (as does your javascript example) that machine readable is
> probably the way to go for this sort of thing.
>
> IANA registries from text have a level of ability to be machine read, but
> aren't really meant to be maintained in the same fashion as code.
>
> YANG structures give us a way to document the format for this sort of
> thing. (There is work elsewhere in IETF covering this.)  But the related
> point would be maintaining the file(s)  covering the expected filters.  I'm
> unaware of work having done such a thing, but perhaps there are others
> on-list that may have suggestions.  The general idea is it should be
> trivial to poke a button on your router and fetch the "IETF approved
> general filter list". (The security considerations for that will be
> terrifying!)
>
> Default filtering procedures for deprecated code points will be
> interesting.  I know many providers that filter those by default already.
> We don't care about this today, and likely may not prior to my retirement,
> but at some point we may need to reuse them.  There's also the related
> conversation about us effectively building an Internet-wide kill-switch for
> someone's feature when that someone isn't playing nice with IETF.  That
> will go badly for all concerned.
>
> The remainder would be operational considerations about how to leverage
> the exclude lists.  Roughly:
> - Implementations SHOULD filter path attributes that aren't intended to be
> used for a given AFI/SAFI by default
> - Implementations providing default filtering MUST provide a mechanism to
> locally update the filter list. (I.e., what's built into the software can't
> be immutable.)
> - Implementations MUST include the ability to override the default
> filters. (This is a "moral" MUST rather than a technical one.</bcp14>)
>
>
> -- Jeff
>
>