Re: [Idr] Feedback on 5575-bis

Christoph Loibl <c@tix.at> Fri, 05 October 2018 09:11 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 A464B130EB9 for <idr@ietfa.amsl.com>; Fri, 5 Oct 2018 02:11:50 -0700 (PDT)
X-Quarantine-ID: <T2JZExqfqMYm>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): X-Spam-Report: ...dback on the draft.\n\t>> [\342\200\246] > > [Some m[...]
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 T2JZExqfqMYm for <idr@ietfa.amsl.com>; Fri, 5 Oct 2018 02:11:45 -0700 (PDT)
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 E9FF8130EA4 for <idr@ietf.org>; Fri, 5 Oct 2018 02:11:44 -0700 (PDT)
Received: from 089144206254.atnat0015.highway.bob.at ([89.144.206.254] helo=[192.168.43.10]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1g8LlK-0002Lk-Oy; Fri, 05 Oct 2018 10:47:07 +0200
From: Christoph Loibl <c@tix.at>
Message-Id: <06EA9BDF-14C4-494B-AB5C-8C5264A10317@tix.at>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6168BC63-8664-40AC-8A33-4270353975AB"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 5 Oct 2018 11:11:40 +0200
In-Reply-To: <20181004162737.GD17157@pfrc.org>
Cc: idr@ietf.org
To: Jeffrey Haas <jhaas@pfrc.org>
References: <20180712185855.GQ12853@pfrc.org> <46D2DE8D-F552-444B-82C8-46DF301B1D10@tix.at> <20181004162737.GD17157@pfrc.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/PXg5QW5oKEOu8h1iS2MEc0GaYJo>
Subject: Re: [Idr] Feedback on 5575-bis
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: Fri, 05 Oct 2018 09:11:59 -0000

Hi Jeff,

> On 04.10.2018, at 18:27, Jeffrey Haas <jhaas@pfrc.org> wrote:
> 
> Christoph,
> 
> On Thu, Oct 04, 2018 at 12:19:27PM +0200, Christoph Loibl wrote:
>> Thank you very much for your detailed feedback on the draft.
>> […]
> 
> [Some moralization about -bis documents.]
> 
> -bis documents are usually issued to clarify or fix broken behaviors.  While
> this often means fixing easy errata, it also means the opportunity to
> address things fundamentally broken in the original specificiation.

I appreciate it very much, that this is moving again :-)

From your reply I distilled the 3 major points (to be honest those were no surprises to me) for additional discussion (not that we should forget about the others and comments are very welcome!):

1) What does BGP know about FS NLRI encoding “opaqueness”:

Most of your arguments lead back to the “opaqueness” property described in RFC5575. I am not so much in favour of propagating garbage. However, changing this behaviour (as specified in RFC5575) was not an action-point that I (I cannot speak for the other authors) considered very useful for better interop. I understand that currently, some implementations do not obey the RFC5575 specification in that particular manner. As a network operator however, I am not so much concerned about this as long as it serves our needs from an operational standpoint (gives us the flexibility and stability that we need - It currently does not, but maybe not because of this particular part of the specification), but I understand that implementation-wise this could be a completely different story.

Do we have better chances that implementations will follow the new specification (and thus increased interoperability + stability) if we discard the “opaqueness” stuff altogether? And, does this lead to a better (less complex, better scalable, …) specification and implementation? If *yes* I am totally in favour of going into that direction. It needs quite a lot changes (which I think, to a large percentage, do not badly break things out there) and some discussion:

*) Reencoding “ghosts”/“duplicates":

The complexity of the NLRI may allow to encode the same thing in multiple ways (I think you pointed that out already). Consider the numeric-operator. For example you may have a comparison for a tcp-port number represented as “=3, =4, =5” or “=4 =5 =3” (this can/should be fixed by having the implementations sort within the components by the numeric-values). However, when it comes to components based on the binary-operator I am not sure if sorting the “bitmasks” is in particular useful (if possible at all - this needs some more thinking). So we may still get some inconsistencies on recoding. - I will look into this next week.

BTW: I am not even sure if recoding the NLRI (even though it creates different versions of the same thing) is a big problem at all. Since we are propagating along a tree (ie AS-path or other intra-AS mechanisms for routing information loop-avoidence).

*) FS Extentions / Gracefully adding new component-types to the NLRI:

Option 1: Treat all NLRIs with unknown components as withdraw
Option 2: specify a component structure for future components that allows unknown components to be dissected/re-encoded and propagated (if desired). [1]
Option 3-: … you name it.
 
[1] - here the URL to my email I referred quite a few times already: http://ietf.10.n7.nabble.com/Feedback-on-5575-bis-tt568777.html#a570460 <http://ietf.10.n7.nabble.com/Feedback-on-5575-bis-tt568777.html#a570460> - please look into paragraph =2= if the mail (the extensibility) - the rest of it has already been brought in this discussion.

*) Propagation of unknown component-types:

In the opaqueness case there cannot be a discussion about this because BGP does not know anything about the components and is propagating all the garbage. If BGP has full understanding of the NLRI - what should happen in case of unknown NLRIs occurring in a BGP message: -> I vote for propagating (but never use it for filtering), but in this case we need to know how do decode unknown components (see above).

2) Interfering Traffic-Actions:

The idea here was to ignore what is not clear. - One could argue that in case of a rate-limit the lowest/highest should win (which?). Or in case of multiple redirect the one with the lowest/highes route-target on that particular node should win. To be honest (from an operator perspective) I am fine with any. We take care about not announcing stupid actions to the network anyway. I agree, that in some cases even multiple redirects can make sense (if finally only one is performed - duplication of the same data stream may not be what is wanted?). What do you + WG think is appropriate. Some simple numeric sorting comes into mind (but as a operator this may mean that you need to assign your route-targets according your preferred FS redirection). - RFC5575 does not specify this at all.

As an operator allowing multiple redirects associated with the same flow filter may arguable seem to be fancy feature, but I would really refrain using that in a production environment. Using my own set of BGP communities to convey that information and rewriting to whatever action is needed at network areas/nodes seems much more flexible to me than depending on a fixed algorithm (policy) that selects redirect targets on my behalf.

3) Default behaviour in case of a flow-match but not *all* actions can be “executed”:

Given the above example (allowing multiple redirects, multiple rate-limits, remarkings, … maybe some other future actions yet unknown) a match always requiring *all* actions to be executed or non (+ being default accept) seems not the right choice. I think that, if traffic actions are not required to be unique and we want some sorting/preference specified (see 2)  we need to come up with something different.

I will upload a new version repairing the minor issues you pointed out (see the previous Email in this thread -  if I see no objections on the list). At the same time I am not changing any of the other aspects (discussed in this Email) until we have a rough idea where we are heading for.

Cheers Christoph

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