[LISPMAP-159] MappingSystem#getWidestNegativePrefix(Eid) returns incorrect results Created: 13/Jun/17  Updated: 19/Oct/17  Resolved: 12/Aug/17

Status: Resolved
Project: lispflowmapping
Component/s: General
Affects Version/s: Carbon
Fix Version/s: None

Type: Bug
Reporter: Lori Jakab Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Issue Links:
Blocks
blocks LISPMAP-157 Negative mapping subscriptions on SB ... Resolved
External issue ID: 8679
Priority: High

 Description   

One of the uses of the MappingSystem#getWidestNegativePrefix(Eid) method is to generate the negative reply to southbound originated Map-Requests which don't get an actual stored mapping as a result. Right now, this method will try to get the widest negative on the NB and if that fails (null is returned) then on the SB.

NB negative prefix will only fail if we try to use an EID that has match, in which case we don'tget to call the method in the first place for this use case, so we never actually get to looking up the widest negative for SB.

Suppose we have a mapping for 192.0.2.0/24 in NB and 10.0.0.0/32 in SB. A mapping lookup for 11.1.1.1 will return 0.0.0.0/1 as the negative mapping, covering 10.0.0.0/8. Instead, it should return the widest negative between 10.0.0.0/32 and 192.0.2.0/24.

So the correct behavior should be to look up both NB and SB widest negative prefixes and return their intersection.

 Comments   
Comment by Lori Jakab [ 13/Jun/17 ]

(In reply to Lori Jakab from comment #0)
> Right now, this method will
> try to get the widest negative on the NB and if that fails (null is
> returned) then on the SB.

Actually, the method will just take the longest prefix from both NB and SB results, which is still incorrect.

Comment by Lori Jakab [ 13/Jun/17 ]

(In reply to Lori Jakab from comment #0)
> Suppose we have a mapping for 192.0.2.0/24 in NB and 10.0.0.0/32 in SB. A
> mapping lookup for 11.1.1.1 will return 0.0.0.0/1 as the negative mapping,
> covering 10.0.0.0/8. Instead, it should return the widest negative between
> 10.0.0.0/32 and 192.0.2.0/24.
>
> So the correct behavior should be to look up both NB and SB widest negative
> prefixes and return their intersection.

Thinking about this further, that wouldn't help. In the above example, NB widest negative is 0.0.0.0/1 and SB widest negative is 128.0.0.0/1, which do not overlap, and thus have no intersection.

We may need to keep a separate radix trie with all prefixes from NB and SB to be able to get the correct widest negative.

Comment by Lori Jakab [ 21/Jun/17 ]

Fix proposed: https://git.opendaylight.org/gerrit/#/c/59206/

Needs cherry-pick to Carbon.

Comment by Lori Jakab [ 12/Aug/17 ]

Carbon cherry-pick: https://git.opendaylight.org/gerrit/#/c/59545/

Generated at Wed Feb 07 20:06:38 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.