Subject: [Idr] Interim followup on draft-ietf-idr-rfc5575bis

From: Christoph Loibl <[email-masked]>
Date: Tue, 6 Nov 2018 16:16:45 +0100

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
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

---

From: Christoph Loibl <[email-masked]>
Date: Wed, 14 Nov 2018 14:39:03 +0100

Hi IDR,

> On 06.11.2018, at 16:16, Christoph Loibl <[email-masked]> wrote:
Since there were no objections: I uploaded a new revision of the draft-ietf-idr-rfc5575bis.  These are the two major changes:

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

1) “opaque” property removed entirely NLRI 

2) Section on extensibility and error-handling (previously this was not necessary since from the theory BGP had no knowledge of the NLRI).

Please review the changes. Feedback is very much appreciated. 

I will proceed working on the flow-action interference as we decided in the interim.

Cheers Christoph