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?
LiZi: For Amsterdam release, there will be only one type of thirdparty sdn
controller for one network, so temporarily in R1, the location will just “Core”
or “Edge”. But infuture it could be geographic. Am I correct? @Zhuoyao
Zhuoyao: Yes, I think so.
黄卓垚 huangzhuoyao
职位 position
承载网管开发部/有线研究院/有线产品经营部 Strategy & IT-IT Dept.
深圳市南山区科技南路55号中兴通讯研发大楼33楼
33/F, R&D Building, ZTE Corporation Hi-tech Road South,
Hi-tech Industrial Park Nanshan District, Shenzhen, P..R.China, 518057
T: +86 755 xxxxxxxx F: +86 755 xxxxxxxx
M: +86 xxxxxxxxxxx
E: huang.zhuo...@zte.com.cn
www.zte.com.cn
原始邮件
发件人：李滋00164331
收件人： <dt5...@att.com>黄卓垚10112215
抄送人： <onap-discuss@lists.onap.org> <jf2...@att.com>
日 期 ：2017年08月29日 19:08
主 题 ：Re: [aai][sdnc] The sdnc schema and Thirdparty-sdnc schema in A&AI
Hi Dan,
Replies sees below.
Thanks,
LiZi
发件人： <dt5...@att.com>
收件人：李滋00164331 <ram...@huawei.com> <kaly...@huawei.com>黄卓垚10112215
<jf2...@att.com>
抄送人： <onap-discuss@lists.onap.org>
日 期 ：2017年08月29日 02:54
主 题 ：Re: [aai][sdnc] The sdnc schema and Thirdparty-sdnc schema in A&AI
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.
LiZi: According to the requirement there need a container to store the
generic-address node, actually, there will be only one address for a thirdparty
SDN Controller.
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.
LiZi: Yes, For Amsterdam, there will be only one instance for each third party
SDN controller. As discussed with Zhuoyao, We have two ways to connect WAN with
third party SDN controller. If I am misunderstand anything please correct me.
1. connect at design time, In SDC there is a way to input Service-type,
for the value we can input vendor to this property. For Amsterdam, we assume
that there will be one controller for each vendor. And then, create a
relationship between WAN controller with thirdparty-sdnc while initial the WAN
controller.
2. connect at runtime, when initial the WAN at runtime, user can query
all the registered thirdparty-sdnc and select one to bind with WAN controller
with lifecycle management portal. This way we need to discuss with the Usecase
UI team.
Since there is less than two weeks for us before the code freeze deadline. So
personaly I suggest we take the aproach 1 for Amsterdam release.
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:
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?
LiZi: For Amsterdam release, there will be only one type of thirdparty sdn
controller for one network, so temporarily in R1, the location will just “Core”
or “Edge”. But infuture it could be geographic. Am I correct? @Zhuoyao
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?
LiZi: Actually, there will be only one generic-address for each
thirdparty-sdnc-info, for A&AI schema, there need a container to nest a node.
Would it be acceptable to assume only one instance of each third party SDN
controller for Amsterdam?
LiZi: Totally, I agree with you.
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?
LiZi: I agree, I think we need a meeting to discuss these issues. If there is
a meeting I will join, I can share what I know and what I am thinking of, but I
don't think I can be the leading role. :-)
Thanks!
Dan
Dan Timoney
Principal Technical Staff Member
AT&T
Email : dtimo...@att.com
Office : +1 (732) 420-3226
Mobile : +1 (201) 960-1211
200 S Laurel Ave, Rm E2-2A03
Middletown, NJ 08873
From: "li.z...@zte.com.cn" <li.z...@zte.com.cn>
Date: Monday, August 28, 2017 at 8:09 AM
To: "ram...@huawei.com" <ram...@huawei.com>, "kaly...@huawei.com"
<kaly...@huawei.com>, "huang.zhuo...@zte.com.cn" <huang.zhuo...@zte.com.cn>,
"TIMONEY, DAN" <dt5...@att.com>
Cc: "onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org>
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
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss
