[SFC-115] SF and SFF "dictionary" mismatch not validated or checked, misconfiguration allowed Created: 14/Oct/15 Updated: 25/May/18 Resolved: 25/May/18 |
|
| Status: | Verified |
| Project: | sfc |
| Component/s: | General |
| Affects Version/s: | unspecified |
| Fix Version/s: | None |
| Type: | Bug | ||
| 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 |
||
| External issue ID: | 4471 |
| Priority: | Normal |
| Description |
|
SF: ] ] SFF: , } , } , } , } SFC: , { "name": "dpi-abstract1", "type": "service-function-type:dpi" } ] SFP: ] RSP: } RSP goes into OPER and SFCOFL2 gets notification: , { "hop-number": 1, "service-index": 254, "service-function-forwarder-locator": "sfc-tun2", "service-function-name": "dpi-74", "service-function-forwarder": "SFF1" } ], RESULT: Partial config, SFF1 creates flows for SF1 but not SF2, SFF2 does nothing. Error in log. Suggested fix: remove all individual references in:
SF model can have multiple DPLs as can SFF. This should be kept in a separate map, where it can be configured as SF-DPL <-> SFF-DPL relationship or it can be discovered. This can also be validated to ensure that transport/DPL type between SF and SFF matches. service-function-mapping.yang doesn't appear in use anywhere, so I'd like to modify it for this purpose. |
| Comments |
| Comment by Brady Johnson [ 10/Feb/16 ] |
|
I submit this patch (merged Dec 1, 2015) to address the problem: |
| Comment by Brady Johnson [ 11/Feb/16 ] |
|
This has been improved with the patch provided, but validation is still not performed. Moving this to Boron. |
| Comment by Brady Johnson [ 25/May/18 ] |
|
This was fixed in Lithium. The SFF.service-function-dictionary.sff-sf-data-plane-locator now has only 2 fields: sf-dpl-name and sff-dpl-name, as follows. As such, the SF DPL info is no longer duplicated. {{{}}
|