LiZi, The current SDN-C design would just use a properties file to map the URL, credentials, etc for one specific instance of a third party SDN controller. f I understand this correctly, it looks like this model allows for multiple addresses for a particular third party SDN controller, which is clearly a good thing but does introduce new complexities.
For Amsterdam, can we make a simplifying assumption that there will be only one instance of each third party SDN controller? If so, then it should be fairly straightforward I think for SDN-C to convert over to using ESR to retrieve the URL and credentials of the third party SDN controller. There are still some details to be worked, like where we’d get the third-party-sdn-id (I’m guessing from TOSCA?), but that should be manageable. If not, then I think there are a few questions/issues we’ll need to resolve to determine how to select the correct third party SDN-C URL and credentials: 1. Is location truly just “Core” or “Edge”, or could it be geographic? In other words, do we need to take geography into account when querying for a third party controller? 2. Each thirdparty-sdnc-info record seems like it can have multiple generic-addresses, but I don’t see a field that tells indicates whether load should be distributed evenly (round-robin) across instances, or if the list is to be treated as priority order (primary, secondary, tertiary, etc). Is that because for Amsterdam, we are assuming always one mode of distribution? Would it be acceptable to assume only one instance of each third party SDN controller for Amsterdam? Separate but related question – the SDN-C developers asked me if I could set up a review of the VoLTE transaction flow for them. Would you be the right person to help us with that, and if so, can we set up a call in the next day or so to do that? Thanks! Dan Dan Timoney Principal Technical Staff Member AT&T Email : [email protected]<mailto:[email protected]> Office : +1 (732) 420-3226 Mobile : +1 (201) 960-1211 200 S Laurel Ave, Rm E2-2A03 Middletown, NJ 08873 From: "[email protected]" <[email protected]> Date: Monday, August 28, 2017 at 8:09 AM To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "TIMONEY, DAN" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [aai][sdnc] The sdnc schema and Thirdparty-sdnc schema in A&AI Dear SDNC Team, According to the feedback from YangXu/Zuoyao and Ramu. The thirdparty SDNC which will registered to AAI/ESR. The schema sees bellow. But maybe there is some relationship between the thirdparty-SDNC and the original SDNC schema or other system. Maybe pnf ? pe? For example there may be a relationship from thirdparty-sdnc-info to pnf and the label is "owns". Anybody from SDNC team can confirm this issue? The attachment is the draft about whole schema of external system. Thanks, LiZi thirdparty-sdnc-info thirdparty-sdnc-id String M Unique ID of third party sdnc item. xml-key location String O such as Core or Edge protocal String O protocal of third party SDNC, for example netconf/snmp. product-name String O generic-addresses ArrayList M resourceVersion String used by A&AI repository relationship-list ArrayList used by A&AI repository generic-address generic-address-id String M xml-key system-name String M vendor String M version String M type String M url String M username String M password String M system-statu String M system-type String M vim/vnfm/sdnc/ems-resource/ems-performance/ems-alarm xml-key resourceVersion String O used by A&AI repository relationship-list ArrayList O used by A&AI repository
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
