[Idr] Extensibility of BGP Flow Specification and draft rfc5575bis

Christoph Loibl <c@tix.at> Mon, 18 November 2019 21:20 UTC

Return-Path: <c@tix.at>
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 E7EDC120B4F for <idr@ietfa.amsl.com>; Mon, 18 Nov 2019 13:20:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 y9yGzgni89Ik for <idr@ietfa.amsl.com>; Mon, 18 Nov 2019 13:20:10 -0800 (PST)
Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F5D12011D for <idr@ietf.org>; Mon, 18 Nov 2019 13:20:10 -0800 (PST)
Received: from 80-110-104-164.cgn.dynamic.surfer.at ([80.110.104.164] helo=[192.168.66.207]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1iWoI2-0001zX-I3 for idr@ietf.org; Mon, 18 Nov 2019 22:10:31 +0100
From: Christoph Loibl <c@tix.at>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ADCBFF74-4EEB-435A-97D9-8F46447FDCE4"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <0E0B21F8-18D8-4BF1-8B1F-CD0FCC0E9CAB@tix.at>
Date: Mon, 18 Nov 2019 22:20:06 +0100
To: "idr@ietf. org" <idr@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bkwzvG6j65ofLss1VdnSuoeosRQ>
Subject: [Idr] Extensibility of BGP Flow Specification and draft rfc5575bis
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: Mon, 18 Nov 2019 21:20:16 -0000

Hi IDR,

I was following the discussion on the IDR WG meeting IETF 106 on extensibility of FlowSpec and there are a few comments that I want to add (see the rfc5575bis draft approach below):

There are quite a few FS extensions in IDR, this is starting get confusing, and does not scale in terms of AFI/SAFI and combination of FS extensions. 

Using a “type-length-(variable-length)value” structure for component types generally looks like a good idea because a parser could easily skip over unknown components as pointed out by John. However I need to point out the following:

1) Propagation of unknown components (if they could be skipped over):

I was learning this over the past few years here: Whenever I suggested something that could potentially propagate garbage and cause problems elsewhere, responses on the mailing list were always arguing strongly against such solutions. If we could skip over FS components we are still not able to decode the component itself. If we still want to propagate it we may cause problems elsewhere.

2) Logical *AND* of component results:

If an unknown component occurs during decoding (even if we could skip over this component) the entire NLRI cannot be used for filtering, since the outcome of the filter has a logical *AND* with an unknown match condition making the result of the entire match unknown.   


Given 1 and 2, what value do we gain if we are actually able to decode the entire NLRI if we do not want to propagate it and we cannot use it for filtering?


****
RFC5575bis approach to extensibility of BGP FS (yes, there is something about extensibility in there):
****

https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/ <https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/>

When we removed the “opaque to BGP” property of the NLRI from the draft (which was in RFC5575 but everyone argued against it, mostly because we do not want to propagate garbage and implementations did not follow that anyway, after the IDR interim in Oct 2018) we added a section on extensibility in rfc5575bis (in order to allow - to some degree - graceful extensions of the NLRI after removing the opaque property). This evolved to Section 11 in the current version:

The basic idea follows the above principles: 1) Do not propagate what you do not understand, 2) Do not filter/match if something appears in the NLRI that you do not understand.
This is achieved by treating the FS NLRI announcement as withdraw whenever the parser encounters an unknown FS component (*not* tearing down the session).

I am not sure if I should dare to say that: Generally, following that proposal, not every extension needs to go for its own AFI/SAFI and we are not polluting the whole AFI/SAFI space with FS nonsense (I already hear a few people shouting at me).

If some filters should only be applied if a specific extension is known to the system rfc5575bis also gives hints how this could be achieved in the last paragraph of section 11.

After implementations have adopted to that behaviour (some already have) introducing new components may not be so much pain.

However I need to point out that extending the FS components may need the implementations to support proper BGP update filtering for FS components. But I leave this to sort out by the extension drafts.   

Cheers Christoph

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at