[Idr] Interim followup on draft-ietf-idr-rfc5575bis
Christoph Loibl <c@tix.at> Tue, 06 November 2018 15:16 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 A9361130E5D; Tue, 6 Nov 2018 07:16:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 h5z0AUj6Yo4k; Tue, 6 Nov 2018 07:16:50 -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 E7CC612870E; Tue, 6 Nov 2018 07:16:49 -0800 (PST)
Received: from [2a01:190:1702:0:b8a4:b473:cefd:add5] by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1gK35U-0004nb-Nc; Tue, 06 Nov 2018 16:16:17 +0100
From: Christoph Loibl <c@tix.at>
Content-Type: multipart/alternative; boundary="Apple-Mail=_686C632B-548E-424C-8FA3-AD74514917F6"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Message-Id: <3778ABA5-1763-483E-A75C-56766D56C4BF@tix.at>
Date: Tue, 06 Nov 2018 16:16:45 +0100
Cc: draft-ietf-idr-rfc5575bis.authors@ietf.org, Jeffrey Haas <jhaas@pfrc.org>
To: idr wg <idr@ietf.org>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/2SafY6Nrp3bRou5wJ8Nts-L2lD4>
Subject: [Idr] Interim followup on draft-ietf-idr-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: Tue, 06 Nov 2018 15:16:54 -0000
Hi IDR, This is a followup on the discussion during the IDR interim the other week. I collected to action points (this mail only includes item -1-): 1) We agreed on removing the opaque-key property entirely (non of the known implementations follow this behaviour) from the draft and add a more relaxed error handling (see the proposed changes below). 2) We try to find out the traffic action interference behaviour of current implementations. If we do not find a common behaviour we try document this instead of breaking current behaviour or features. (I will send a mail regarding this later) Below the changes that I propose to the draft in order to remove the opaque-key property (this fits very much the known implementations of the protocol). Since we break propagation of garbage (and also unknown future FS NLRI extensions) according to RFC5575, I also added a section on graceful error handling and extensibility. Feedback on these changes from the WG are very much appreciated. I will publish a -10 including these changes if no objections. Cheers Christoph Section 3., paragraph 4: OLD: BGP itself treats the NLRI as an opaque key to an entry in its databases. Entries that are placed in the Loc-RIB are then associated with a given set of semantics, which is application dependent. This is consistent with existing BGP applications. For instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast reverse-path information (AFI=1, SAFI=2) are handled by BGP without any particular semantics being associated with them until installed in the Loc-RIB. NEW: BGP itself treats the NLRI as an key to an entry in its databases. Entries that are placed in the Loc-RIB are then associated with a given set of semantics, which is application dependent. This is consistent with existing BGP applications. For instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast reverse-path information (AFI=1, SAFI=2) are handled by BGP without any particular semantics being associated with them until installed in the Loc-RIB. Section 4., paragraph 1: OLD: We define a "Flow Specification" NLRI type (Figure 1) that may include several components such as destination prefix, source prefix, protocol, ports, and others (see Section 4.2 below). This NLRI is treated as an opaque bit string prefix by BGP. Each bit string identifies a key to a database entry with which a set of attributes can be associated. NEW: We define a "Flow Specification" NLRI type (Figure 1) that may include several components such as destination prefix, source prefix, protocol, ports, and others (see Section 4.2 below). NEW: 11. Error-Handling and Future NLRI Extensions In case BGP encounters an error in a Flow Specification UPDATE message it SHOULD treat this message as Treat-as-withdraw according to [RFC7606] Section 2. Possible reasons for an error are (for more reasons see also [RFC7606]): o Incorrect implementation of this specification - the encoding of the NLRI or traffic action extended-communities do not comply with this specification. o Unknown Flow Specification extensions - The sending party has implemented a Flow Specification NLRI extension unknown to the receiving party. In order to facilitate future extensions of the Flow Specification NLRI such extensions SHOULD specify a way to encode a "always-true" match condition within the newly introduced components. This match condition can be used to propagate (and apply) certain filters only if a specific extension is known to the implemenation. -- Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at
- [Idr] Interim followup on draft-ietf-idr-rfc5575b… Christoph Loibl
- Re: [Idr] Interim followup on draft-ietf-idr-rfc5… Christoph Loibl