[LISPMAP-155] SMR scheduler task tracking unreliable Created: 16/May/17 Updated: 20/Mar/18 Resolved: 16/Aug/17 |
|
| Status: | Resolved |
| Project: | lispflowmapping |
| Component/s: | General |
| Affects Version/s: | Carbon |
| Fix Version/s: | Oxygen |
| Type: | Bug | Priority: | Highest |
| 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 |
||
| External issue ID: | 8469 |
| Priority: | High |
| Description |
|
The SmrScheduler inner class in MapServer has a multi-level data structure to track outstanding SMRs. However, the level are not sufficient to reliably track all tasks. At the top level are subscriber RLOCs, followed by EIDs. However, (original) source EIDs are also needed for uniquely identifying requests, and they are missing. As a result it's impossible to retrieve and cancel the right task. |
| Comments |
| Comment by Lori Jakab [ 11/Aug/17 ] |
|
This was partially solved in https://git.opendaylight.org/gerrit/#/c/57786/ There is a patch to fix integration tests to respond to SMRs with an SMR-invoked Map-Request to exercise this code. Looking at the integration test logs, I found an issue with the tracking of EIDs at the top level Map: Eid prefixes get serialized to the Source EID field of the SMR Map-Request packet, a where no prefix length can be stored, so it is lost. As a result, the xTR will use the Source EID field from the SMR to generate the Eid in the SMR-invoked Map-Request, adding the maximum prefix length (32 and 128 respectively for IPv4 and IPv6). This deserialized EID will be used as a lookup key in the Map, and unless the original Eid had maximum prefix length, it won't match. |
| Comment by Lori Jakab [ 11/Aug/17 ] |
|
Fix proposed: https://git.opendaylight.org/gerrit/#/c/61556/ Needs to go in before Sunday 8/13 to make it to Carbon SR2: https://lists.opendaylight.org/pipermail/release/2017-August/011948.html |