[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