[GBP-28] Move assignment of TunnelID to SourceMapper from DestinationMapper Created: 02/May/15 Updated: 15/May/15 Resolved: 15/May/15 |
|
| Status: | Resolved |
| Project: | groupbasedpolicy |
| Component/s: | General |
| Affects Version/s: | unspecified |
| Fix Version/s: | None |
| Type: | Improvement | ||
| Reporter: | Keith Burns | Assignee: | Keith Burns |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Description |
|
With the separation of network_containment from EPG, the tunnelID no longer simply reflects the Source EPG, but a combination of information that is lost when sending to a Destination on a remote node. This required a change to DestinationMapper, to correctly assign the appropriate TunnelID based on source EP information (network_containment AND its mEPG ordinal). The change added matchers in DestMapper based on Source EP. These additional combinatorial flows can be avoided by simply: 1. Assigning the TunnelID in SourceMapper Note that this needs to be tested, as per all routing, in a complex environment, such as the neutron integration lab. (EPs in (x * network_containments) * (y * EPGs)) where networkcontainments should be a number of subnets/networks and routers (multiple FD,BD,L3C) and multiple EPGs to TRULY test we aren't accidentally overloading things. |
| Comments |
| Comment by Keith Burns [ 02/May/15 ] |
|
In case someone other than me picks this up, note that the point is to remove the unnecessary matchers from DestinationMapper as part of this, not to simply move the tunId assignment from one place to another. |
| Comment by Keith Burns [ 12/May/15 ] |
|
Fix in Gerrit undergoing QA, but works locally in my branch. |