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

Jeffrey Haas <> Wed, 28 October 2020 20:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F9883A0980; Wed, 28 Oct 2020 13:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VR57FwYZAuHU; Wed, 28 Oct 2020 13:42:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F2AAD3A0975; Wed, 28 Oct 2020 13:42:58 -0700 (PDT)
Received: by (Postfix, from userid 1001) id EE2661E351; Wed, 28 Oct 2020 16:58:09 -0400 (EDT)
Date: Wed, 28 Oct 2020 16:58:09 -0400
From: Jeffrey Haas <>
To: "Jakob Heitz (jheitz)" <>
Cc: John Scudder <>, "" <>, Robert Raszuk <>, "" <>, "" <>, Hares Susan <>
Message-ID: <>
References: <> <3366_1601300732_5F71E8FC_3366_6_3_53C29892C857584299CBF5D05346208A48F86028@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Oct 2020 20:43:02 -0000

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