Re: [Idr] Feedback on 5575-bis

[Christoph Loibl <[e-mail]>]

Hi Jeff and IDR,

Thanks for your very detailed review of the draft. It is a very valuable piece of work. We already started working on this (identifying/categorising issues, preparing possible solutions for the list). This will unfortunately still take some time (due to vacations, …).

One of our goals for the -bis is that we do *not* want to break the implemenations of RFC5575 with the -bis revision. Even if we keep that in mind, quite a few issues you pointed out can be resolved very easily, since the implementations already seem to agree on many points, even though it is left open by the RFC5575 and this agreement seems to be based on assumptions.

While I promise that we will send a complete report on all the issues pointed out to the list, I want to start/continue a discussion on extensibility of Flow Spec and possible options to open the door for future (and already pending in the queue) FS extensions in the -bis without breaking anything already out there:


> On 12.07.2018, at 20:58, Jeffrey Haas <[e-mail]> wrote:
> This issue in validation, as I tersely noted in a prior IDR thread, really
> needs discussion in the document.  It impacts the ability to verify, to add
> new component types, and potentially cause invalid NLRI to propagate
> downstream.
> 
> :   The <type, value> encoding is chosen in order to allow for future
> :   extensibility.
> 
> It should be mentioned that due to the property above that extensions are
> problematic.

1) How can BGP possibly verify the correct structure of the FS NLRI, and does it need to?

cited from RFC5575:
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 fundamental to the protocol and I do not think that changing this in the -bis is a very good idea (however, I am aware that not all implementations actually comply to the standard in this particular manner - see the next paragraph why this may be the case). What was also pointed out - as a resulting drawback - on the list, is that garbage gets propagated over the entire FS domain (as with any other opaque attribute).

However, there is a weird thing to note about the “opacity” of FS NLRI: When it comes to validation (section 6 of RFC5575; this is where we check the NLRI dst-ip component against the unicast-routing) the NLRI seems *less* opaque. Actually BGP *needs* to decode the FS NLRI to some certain degree, otherwise it is unable to perform the validation (needed for accepting and propagating the prefix). However, it needs to be pointed out that even if there are unknown FS components in the NLRI, decoding the dst-ip will always work fine, since the components MUST be sorted by the type in ascending order (thus the dst-ip component is always the first! As long as there is no new type=0 component introduced this should be fine -> ToDo: add to IANA section to reserve type=0 component!)

I still favour to some degree the "opaque key” property because this way we make sure that “re-encoding” does not happen, and the encoding of the NLRI is consistent over the entire FS domain. Recoding (decode -> store -> encode -> propagate) of the NLRI means that BGP may generate ghost versions of FS NLRIs because they choose a different encoding on propagation (like you (Jeff) asked “shall we reorder the FS components” -> I do not think so, because that potentially creates a ghost NLRI - if it is incorrect we can still treat it as withdraw (given we even more relax the *opaque* property of the protocol (what I am not so much on favour of)).


2) Now to the extensibility:

If BGP does not decode the NLRI further than to the type=1 (dst-ip) component(**) (which needs to appear in the first place anyway) we are fine. BGP can decode what it needs to and propagate it along with the rest of the (potentially) garbage NLRI to its peers (as it should do now - according to the specs). If we still want to verify even unknown FS components to some certain degree (while being compatible with the current specification RFC 5575 - and having an upgrade path) I would propose something like this:

If an unknown component type (not specified by this document) is encountered, the following encoding should be assumed:

<type (1 octet), length (2 octet), data (length octets)>

Future Flow Specification extensions MUST implement the above component encoding. If a unknown component is encountered, this prefix cannot be used for traffic filtering purposes (but MUST still be taken into account for BGP propagation). If a component type is known by the implementation but its length is set to 0 this component always evaluates to true.

Something along these lines may gracefully allow extensions while not breaking anything out there right from the start. It also gives BGP the ability to verify the NLRI to some certain degree. Additionally the length=0 case may allow to select rules that are not actually making use of a new component, but should only be applied if the implementation implements this particular extension.

note(**): should we put into the -bis that verification always fails if there is _no_ type=1 component in the NLRI? Or should we assume 0.0.0.0/0 as dst-ip during verification?


I am aware that this may be a lengthy discussion, however please bear the following in mind:

This discussion is *not* about a possible Flow Spec 2.0! We want to retain compatibility to RFC 5575. We want to specify what is currently mostly based on assumptions by the different implementations. We want to eliminate inconsistencies and enhance extensibility if possible. And we want to get it right on the second try :-)

Please let us think along those lines in the discussion.

This is also why I think that your (Jeff) review is very valuable to the quality of this -bis draft. It will definitely help to eliminate quite a few uncertainties still left over from the current standards document.

Christoph

--
Christoph Loibl
[e-mail] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at