Re: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

[Jeffrey Haas <[e-mail]>]

I have been unable to follow IETF properly in recent times, so forgive this
stale comment for the archive:

On Tue, Sep 29, 2020 at 03:31:33PM +0000, Jakob Heitz (jheitz) wrote:
> This may have had something to do with getting an interface specific flowspec. There was debate about putting the interface specification as part of the NLRI or part of the attributes. My memory is leaking.

When the authors of the interface-set draft were discussing encoding
considerations, we had two things that came out of that discussion relevant
to this thread:

1. We were aware that implementations that didn't understand a new component
type may have difficulties enforcing the intent of the interface-set
scoping.  Given this text from RFC 5575, that's potentially problematic:

:   If a given component type within a prefix in unknown, the prefix in
:   question cannot be used for traffic filtering purposes by the
:   receiver

At that time, the magnitude of the issues surrounding extending flowspec
weren't totally understood.

2. The inter-domain considerations for interface-set group ids was
problematic.  Such group ids were likely to be applicable to one domain and
may not be useful inter-domain; i.e. customer to ISP.  Since there was a
likelihood of needing to be able to change the mappings somewhat
dynamically, this was more applicable to a path attribute that could be
readily modified.  In this case we chose extended communities.

There is also the problem that if it were encoded in the NLRI, that would
mean that the NLRI itself would need a rewrite when crossing such
boundaries.  Our general experience with BGP over the years usually suggests
that this is a recipe for disaster.

-- Jeff