Re: [Idr] Feedback on 5575-bis

[Christoph Loibl <[e-mail]>]

Hi Jeff, IDR,

I am trying to write a summary on FS propagation in a non-opaque way (=BGP fully understanding of the NLRI + regenerating the byte-string) - Jeff: as you pointed out this is already the case with some of the implementations. I just want to better understand what we need to think of in case we want to go into that direction. (Questions at the end)

In one of my last emails I wrote that I think re-encoding of the FS NLRI may be dangerous because it may result in a different NLRIs getting created and propagated (see below). For example a simple tcp-port filter (port 137,138) can be encoded as: 

port == 137 || port == 138
port == 138 || port == 137
port >= 137 && port <= 138
…

The NLRI itself can express the same filter in multiple ways (I doubt, that we can change the specification to have a 1:1 mapping filter to NLRI without throwing the hole thing away - which I think is not at all desirable). 
	
> On 04.10.2018, at 18:27, Jeffrey Haas <[e-mail]> wrote:
> 
>> CL: NLRI re-en-coding is not acceptable since it introduces a hole lot of problems. Opaqueness of the NLRI to BGP is somehow vital to avoid such situations altogether. See also the comment above [1].
> 
> See again prior comments.  Many implementations build data structurres from
> received NLRI.  If you understand it, you may regenerate it in canonical
> order.


I agree. Actually, I think that some of the behaviour that we observed in the lab years ago can be explained very well by this.

My questions here: 
------------------------

*) If the NLRI itself can express the same filter in multiple ways (see above). May regenerating the NLRI from a data structure produce a different NLRI byte-string (“ghost”)?

(I would say yes? - potentially) 

*) What are the implications if “ghost” NLRIs get propagated?

The propagation of the NLRI follows a tree from neighbor to neighbor (loops getting resolved by As-path, cluster-lists, … = independently from the NLRI itself) … withdraw follows the same mechanisms. However BGP-speakers may receive different byte-string versions of the same NLRI and maybe even treat both as two different routes (maybe propagating 2 NLRIs instead of one)? Is this something, that can also happen with other NLRIs? Is this dangerous?

Cheers Christoph

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