Re: [Idr] Feedback on 5575-bis

[Christoph Loibl <[e-mail]>]

Hi Jeff,

> On 04.10.2018, at 18:27, Jeffrey Haas <[e-mail]> 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
[e-mail] <mailto:[e-mail]> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at <http://www.nextlayer.at/>