Re: [onap-discuss] Invitation: PNF support in R1 vCPE use case @ Tue Jan 9, 2018 5:30am - 6:30am (PST) (yoav.klu...@amdocs.com)

2018-01-08 Thread Yoav Kluger
Thanks Kenny.

All,

This is the meeting we agreed on this morning. The subject has remained the 
same but what is actually planned is to go over Oscar’s proposal for PNF 
support and hopefully make a decision on our direction, which will in turn 
derive the requirements for the different projects.

Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278



-Original Appointment-
From: ONAP Meetings and Events 
[mailto:linuxfoundation.org_1rmtb5tpr3uc8f76fmflplo...@group.calendar.google.com]
Sent: Monday, January 08, 2018 7:54 PM
To: ONAP Meetings and Events; onap-discuss@lists.onap.org; Yoav Kluger
Subject: Invitation: PNF support in R1 vCPE use case @ Tue Jan 9, 2018 5:30am - 
6:30am (PST) (yoav.klu...@amdocs.com)
When: Tuesday, January 09, 2018 3:30 PM-4:30 PM (UTC+02:00) Jerusalem.
Where: https://zoom.us/j/672869780


more details 
»<https://www.google.com/calendar/event?action=VIEW=a2p2YTRmNmNsbGM3aGk1aWVwOGwxZ3A2OGsgeW9hdi5rbHVnZXJAYW1kb2NzLmNvbQ=NzIjbGludXhmb3VuZGF0aW9uLm9yZ18xcm10YjV0cHIzdWM4Zjc2Zm1mbHBsb2k4OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tNTU5YTg1ZGJlNmY3NDE4MDIyMDZlNDRjODAwYTQyNTM2ZDE2M2YzYw=America/Los_Angeles=en>

PNF support in R1 vCPE use case
When
Tue Jan 9, 2018 5:30am – 6:30am Pacific Time

Where
https://zoom.us/j/672869780 
(map<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F672869780=D=2=AFQjCNEVdC9R1F2s_EfOlpP8IzUuEdEyzw>)

Calendar
yoav.klu...@amdocs.com

Who
•
kp...@linuxfoundation.org - creator

•
onap-discuss@lists.onap.org

•
yoav.klu...@amdocs.com



Hi there,

ONAP Meeting 9 is inviting you to a scheduled Zoom meeting.
Join from PC, Mac, Linux, iOS or Android: 
https://zoom.us/j/672869780<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F672869780=D=2=AFQjCNEVdC9R1F2s_EfOlpP8IzUuEdEyzw>
Or iPhone one-tap :
US: +16465588656,,672869780# or +16699006833,,672869780#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 
369 0926 (Toll Free)
Meeting ID: 672 869 780
International numbers available: 
https://zoom.us/zoomconference?m=oKMdZPDVcb67AawvjWqQ_xHUX43prdSf<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fzoomconference%3Fm%3DoKMdZPDVcb67AawvjWqQ_xHUX43prdSf=D=2=AFQjCNH36p7iljeuXCvcn39JbiukiMTnHQ>




Going?   
Yes<https://www.google.com/calendar/event?action=RESPOND=a2p2YTRmNmNsbGM3aGk1aWVwOGwxZ3A2OGsgeW9hdi5rbHVnZXJAYW1kb2NzLmNvbQ=1=NzIjbGludXhmb3VuZGF0aW9uLm9yZ18xcm10YjV0cHIzdWM4Zjc2Zm1mbHBsb2k4OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tNTU5YTg1ZGJlNmY3NDE4MDIyMDZlNDRjODAwYTQyNTM2ZDE2M2YzYw=America/Los_Angeles=en>
 - 
Maybe<https://www.google.com/calendar/event?action=RESPOND=a2p2YTRmNmNsbGM3aGk1aWVwOGwxZ3A2OGsgeW9hdi5rbHVnZXJAYW1kb2NzLmNvbQ=3=NzIjbGludXhmb3VuZGF0aW9uLm9yZ18xcm10YjV0cHIzdWM4Zjc2Zm1mbHBsb2k4OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tNTU5YTg1ZGJlNmY3NDE4MDIyMDZlNDRjODAwYTQyNTM2ZDE2M2YzYw=America/Los_Angeles=en>
 - 
No<https://www.google.com/calendar/event?action=RESPOND=a2p2YTRmNmNsbGM3aGk1aWVwOGwxZ3A2OGsgeW9hdi5rbHVnZXJAYW1kb2NzLmNvbQ=2=NzIjbGludXhmb3VuZGF0aW9uLm9yZ18xcm10YjV0cHIzdWM4Zjc2Zm1mbHBsb2k4OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tNTU5YTg1ZGJlNmY3NDE4MDIyMDZlNDRjODAwYTQyNTM2ZDE2M2YzYw=America/Los_Angeles=en>
more options 
»<https://www.google.com/calendar/event?action=VIEW=a2p2YTRmNmNsbGM3aGk1aWVwOGwxZ3A2OGsgeW9hdi5rbHVnZXJAYW1kb2NzLmNvbQ=NzIjbGludXhmb3VuZGF0aW9uLm9yZ18xcm10YjV0cHIzdWM4Zjc2Zm1mbHBsb2k4OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tNTU5YTg1ZGJlNmY3NDE4MDIyMDZlNDRjODAwYTQyNTM2ZDE2M2YzYw=America/Los_Angeles=en>
Invitation from Google Calendar<https://www.google.com/calendar/>

You are receiving this courtesy email at the account yoav.klu...@amdocs.com 
because you are an attendee of this event.
To stop receiving future updates for this event, decline this event. 
Alternatively you can sign up for a Google account at 
https://www.google.com/calendar/ and control your notification settings for 
your entire calendar.
Forwarding this invitation could allow any recipient to modify your RSVP 
response. Learn 
More<https://support.google.com/calendar/answer/37135#forwarding>.
 << File: invite.ics >>

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 
<https://www.amdocs.com/about/email-disclaimer>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


Re: [onap-discuss] vCPE closed loop testing session

2017-10-09 Thread Yoav Kluger
Excellent!
And saves an edit to the diagram :)

From: Kang Xi [mailto:kang...@huawei.com]
Sent: Monday, October 09, 2017 5:45 PM
To: Yoav Kluger <yoav.klu...@amdocs.com>; onap-discuss 
<onap-discuss@lists.onap.org>
Subject: RE: vCPE closed loop testing session

Yoav,

During the test session Brian said that appc now has this feature to query AAI 
to get vserver ID from vnf ID. So we will let appc do it.
--
Regards,
Kang
From:Yoav Kluger
To:Kang Xi,onap-discuss,
Date:2017-10-09 17:28:09
Subject:RE: vCPE closed loop testing session

Turns out I was not the last one editing this diagram, so I don't have the 
up-to-date source.
Whoever has it - please either make the change or send me the link to the 
source of the diagram so I can make the change.

Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278
[amdocs-a]

From: Kang Xi [mailto:kang...@huawei.com]
Sent: Thursday, October 05, 2017 6:03 PM
To: Yoav Kluger <yoav.klu...@amdocs.com<mailto:yoav.klu...@amdocs.com>>; 
onap-discuss <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>
Subject: RE: vCPE closed loop testing session

Yoav,

Thanks for the info. Very important.
--
Regards,
Kang
From:Yoav Kluger
To:Kang Xi,onap-discuss,
Date:2017-10-05 17:39:29
Subject:RE: vCPE closed loop testing session

Kang,

Just a small correction in steps 5 and 6 below:
5.  Policy process the event from DCAE, queries AAI to obtain the vServer 
ID, and sends a "restart" event to APPC through DMaaP with the vServerID as a 
parameter
6.   APPC captures the event from Policy, and restarts the VM according to 
the vServerID received from Policy

We were initially going to have APPC query AAI to get the vServerID, but it 
then turned out that APPC would not be able to do this for R1 so Policy will do 
it as it does today in the vFW use case. Hopefully APPC is able to do the query 
in R2 so we will go back to how we wanted to do this originally, which is more 
"right".

I think the wiki still has it the original way - I will update.

Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278
[cid:image002.jpg@01D34126.A11C8580]


-Original Appointment-
From: Kang Xi [mailto:kang...@huawei.com]
Sent: Thursday, October 05, 2017 3:58 PM
To: onap-discuss
Subject: [onap-discuss] vCPE closed loop testing session
When: Friday, October 06, 2017 1:00 PM-4:00 PM (UTC-05:00) Eastern Time (US & 
Canada).
Where: https://zoom.us/j/44


Hi DCAE, CLAMP, Policy, APPC, AAI,

Please join this session to kick off vCPE closed loop testing. The environment 
is in the community open lab. Marco has installed ONAP under integration 
project. Vijay has manually set up DCAE VES collector and TCA and has verified 
that they are working.

We will create a vGMUX VM for this testing. What to be tested include the 
following:
1.  Design and load policy rules t policy engine. Ideally this should be 
done by CLAMP. In case of problems, the workaround is to use Policy GUI.
2.  Preload AAI with vCPE data. The purpose is to lookup vServer using 
vGMUX VNF ID.
3.  vGMUX sends packet loss VES to DCAE VES collector
4.   DCAE TCA sends an event to Policy through DMaaP
1.   Policy process the event from DCAE and sends a "restart" event to APPC 
through DMaaP
1.   APPC captures the event from Policy, extracts the VNF ID from the 
event, queries AAI to obtain the vServer ID, and then restarts the VM

If you have not yet obtained access to the open lab, please open a jira ticket 
and assign it to Stephen Gooch to request one. Once you get your account, you 
can set up an OpenVPN connection to the lab and access all the resources there.

Thanks,
Kang

  << File: ATT1.txt >>

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 
<https://www.amdocs.com/about/email-disclaimer>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


Re: [onap-discuss] vCPE closed loop testing session

2017-10-09 Thread Yoav Kluger
Turns out I was not the last one editing this diagram, so I don't have the 
up-to-date source.
Whoever has it - please either make the change or send me the link to the 
source of the diagram so I can make the change.

Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278
[amdocs-a]

From: Kang Xi [mailto:kang...@huawei.com]
Sent: Thursday, October 05, 2017 6:03 PM
To: Yoav Kluger <yoav.klu...@amdocs.com>; onap-discuss 
<onap-discuss@lists.onap.org>
Subject: RE: vCPE closed loop testing session

Yoav,

Thanks for the info. Very important.
--
Regards,
Kang
From:Yoav Kluger
To:Kang Xi,onap-discuss,
Date:2017-10-05 17:39:29
Subject:RE: vCPE closed loop testing session

Kang,

Just a small correction in steps 5 and 6 below:
5.  Policy process the event from DCAE, queries AAI to obtain the vServer 
ID, and sends a "restart" event to APPC through DMaaP with the vServerID as a 
parameter
6.   APPC captures the event from Policy, and restarts the VM according to 
the vServerID received from Policy

We were initially going to have APPC query AAI to get the vServerID, but it 
then turned out that APPC would not be able to do this for R1 so Policy will do 
it as it does today in the vFW use case. Hopefully APPC is able to do the query 
in R2 so we will go back to how we wanted to do this originally, which is more 
"right".

I think the wiki still has it the original way - I will update.

Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278
[cid:image002.jpg@01D34123.EEBD71D0]


-Original Appointment-
From: Kang Xi [mailto:kang...@huawei.com]
Sent: Thursday, October 05, 2017 3:58 PM
To: onap-discuss
Subject: [onap-discuss] vCPE closed loop testing session
When: Friday, October 06, 2017 1:00 PM-4:00 PM (UTC-05:00) Eastern Time (US & 
Canada).
Where: https://zoom.us/j/44


Hi DCAE, CLAMP, Policy, APPC, AAI,

Please join this session to kick off vCPE closed loop testing. The environment 
is in the community open lab. Marco has installed ONAP under integration 
project. Vijay has manually set up DCAE VES collector and TCA and has verified 
that they are working.

We will create a vGMUX VM for this testing. What to be tested include the 
following:
1.  Design and load policy rules t policy engine. Ideally this should be 
done by CLAMP. In case of problems, the workaround is to use Policy GUI.
2.  Preload AAI with vCPE data. The purpose is to lookup vServer using 
vGMUX VNF ID.
3.  vGMUX sends packet loss VES to DCAE VES collector
4.   DCAE TCA sends an event to Policy through DMaaP
1.   Policy process the event from DCAE and sends a "restart" event to APPC 
through DMaaP
1.   APPC captures the event from Policy, extracts the VNF ID from the 
event, queries AAI to obtain the vServer ID, and then restarts the VM

If you have not yet obtained access to the open lab, please open a jira ticket 
and assign it to Stephen Gooch to request one. Once you get your account, you 
can set up an OpenVPN connection to the lab and access all the resources there.

Thanks,
Kang

  << File: ATT1.txt >>

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 
<https://www.amdocs.com/about/email-disclaimer>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


Re: [onap-discuss] vCPE closed loop testing session

2017-10-05 Thread Yoav Kluger
Kang,

Just a small correction in steps 5 and 6 below:
1.  Policy process the event from DCAE, queries AAI to obtain the vServer 
ID, and sends a "restart" event to APPC through DMaaP with the vServerID as a 
parameter
2.  APPC captures the event from Policy, and restarts the VM according to 
the vServerID received from Policy

We were initially going to have APPC query AAI to get the vServerID, but it 
then turned out that APPC would not be able to do this for R1 so Policy will do 
it as it does today in the vFW use case. Hopefully APPC is able to do the query 
in R2 so we will go back to how we wanted to do this originally, which is more 
"right".

I think the wiki still has it the original way - I will update.

Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278



-Original Appointment-
From: Kang Xi [mailto:kang...@huawei.com]
Sent: Thursday, October 05, 2017 3:58 PM
To: onap-discuss
Subject: [onap-discuss] vCPE closed loop testing session
When: Friday, October 06, 2017 1:00 PM-4:00 PM (UTC-05:00) Eastern Time (US & 
Canada).
Where: https://zoom.us/j/44


Hi DCAE, CLAMP, Policy, APPC, AAI,

Please join this session to kick off vCPE closed loop testing. The environment 
is in the community open lab. Marco has installed ONAP under integration 
project. Vijay has manually set up DCAE VES collector and TCA and has verified 
that they are working.

We will create a vGMUX VM for this testing. What to be tested include the 
following:
3.  Design and load policy rules t policy engine. Ideally this should be 
done by CLAMP. In case of problems, the workaround is to use Policy GUI.
4.  Preload AAI with vCPE data. The purpose is to lookup vServer using 
vGMUX VNF ID.
5.  vGMUX sends packet loss VES to DCAE VES collector
6.  DCAE TCA sends an event to Policy through DMaaP
1.  Policy process the event from DCAE and sends a "restart" event to APPC 
through DMaaP
1.  APPC captures the event from Policy, extracts the VNF ID from the 
event, queries AAI to obtain the vServer ID, and then restarts the VM

If you have not yet obtained access to the open lab, please open a jira ticket 
and assign it to Stephen Gooch to request one. Once you get your account, you 
can set up an OpenVPN connection to the lab and access all the resources there.

Thanks,
Kang

  << File: ATT1.txt >>

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 
<https://www.amdocs.com/about/email-disclaimer>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


Re: [onap-discuss] vCPE deep dive session in Paris

2017-09-24 Thread Yoav Kluger
Kang, all,

The big advantage of the current time slot (12:30-13:15) is that there is no 
other discussion currently planned for this slot, which will allow many people 
to attend.
In the time slot you propose to move it to there are already 3 interesting 
sessions scheduled, which will result in many people missing our session even 
though they would be interested in joining.
As for time zones I think 6:30am for eastern U.S. is reasonable, and in 
particular Gil will attend, and we would only lose potential remote 
participants in other u.s. time zones.

So between definitely losing many people locally, vs. potentially losing some 
remotely – I prefer the latter, i.e. to not move our session.

Yoav

From: BULLARD, GIL [mailto:wb5...@att.com]
Sent: Friday, September 22, 2017 10:23 PM
To: Kang Xi <kang...@huawei.com>; Yoav Kluger <yoav.klu...@amdocs.com>
Cc: Yunxia Chen <helen.c...@huawei.com>; SPATSCHECK, OLIVER 
<spat...@research.att.com>; LEFEVRE, CATHERINE <cl6...@intl.att.com>; JI, 
LUSHENG <l...@research.att.com>; CHOMA, JOHN S <jc1...@att.com>; Zhou, Danny 
<danny.z...@intel.com>; PLATANIA, MARCO <plata...@research.att.com>; FREEMAN, 
BRIAN D <bf1...@att.com>; SHACHAM, RON <rshac...@research.att.com>; ZINNIKAS, 
MICHAEL J <mz2...@att.com>; SHAH, SARYU D <ss3...@att.com>; NEKRASSOV, ALEXEI 
<an4...@att.com>; VENKATESH KUMAR, VIJAY <vv7...@att.com>; ROSE, DANIEL V 
<dr6...@att.com>; TIMONEY, DAN <dt5...@att.com>; ZITELLA, MICHAEL V 
<mz1...@att.com>; DAUGHERTY, ROBERT E <rd4...@att.com>; Pawlowski Michal 1 - 
Korpo <michal.pawlows...@orange.com>; Yoav Kluger <yoav.klu...@amdocs.com>; Li, 
Johnson <johnson...@intel.com>; Geora Barsky <geo...@amdocs.com>; MARTELLA, 
ARTHUR <amart...@research.att.com>; DeWayne Filppi <dewa...@cloudify.co>; Alla 
Goldner <alla.gold...@amdocs.com>
Subject: RE: vCPE deep dive session in Paris

Kang,
I can support either time.

Note that I have posted to the “drafts” page on the wiki the slides that I plan 
to talk from:
https://wiki.onap.org/display/DW/Residential+Broadband+vCPE+Drafts+for+discussion?focusedCommentId=15997611=1506107321110#comment-15997611

As an FYI, you will see that the slides have a lot of information, but do not 
conclude that I will attempt to talk to that detail in my allotted 15 minutes.  
I have purposely shrunk pictures down to small font so that no one in the 
audience is tempted to try to read that detail during the presentation.  My 
purpose is to use the diagrams on the slide only to generally convey the topic 
which I will be addressing verbally.  I will ask the audience to focus only on 
the boxes and sticks... no fine text on the slides.  I plan to basically speak 
to the verbiage in the yellow callouts, which capture the “take away” points on 
each slide.  The audience can come back and read the details later if they 
would like.

Team,
Please comment if you have any feedback on the slides.  Comments are 
appreciated.  Particularly:

· DeWayne - can you verify that I have done a good job in my yellow 
callout text of articulating our “Stretch” goal for Release 1?

· Dan T, Rob D, John C, Daniel R – can you verify that I have done a 
good job in my yellow callout text of relating the system functionality for 
Release 1?

Gil


From: Kang Xi [mailto:kang...@huawei.com]
Sent: Friday, September 22, 2017 10:36 AM
To: BULLARD, GIL <wb5...@att.com<mailto:wb5...@att.com>>; KLUGER, YOAV 
<yoav.klu...@amdocs.com<mailto:yoav.klu...@amdocs.com>>
Cc: Yunxia Chen <helen.c...@huawei.com<mailto:helen.c...@huawei.com>>; 
SPATSCHECK, OLIVER <spat...@research.att.com<mailto:spat...@research.att.com>>; 
LEFEVRE, CATHERINE <cl6...@intl.att.com<mailto:cl6...@intl.att.com>>; JI, 
LUSHENG <l...@research.att.com<mailto:l...@research.att.com>>; CHOMA, JOHN S 
<jc1...@att.com<mailto:jc1...@att.com>>; BULLARD, GIL 
<wb5...@att.com<mailto:wb5...@att.com>>; Zhou, Danny 
<danny.z...@intel.com<mailto:danny.z...@intel.com>>; PLATANIA, MARCO 
<plata...@research.att.com<mailto:plata...@research.att.com>>; FREEMAN, BRIAN D 
<bf1...@att.com<mailto:bf1...@att.com>>; SHACHAM, RON 
<rshac...@research.att.com<mailto:rshac...@research.att.com>>; ZINNIKAS, 
MICHAEL J <mz2...@att.com<mailto:mz2...@att.com>>; SHAH, SARYU D 
<ss3...@att.com<mailto:ss3...@att.com>>; NEKRASSOV, ALEXEI 
<an4...@att.com<mailto:an4...@att.com>>; VENKATESH KUMAR, VIJAY 
<vv7...@att.com<mailto:vv7...@att.com>>; ROSE, DANIEL V 
<dr6...@att.com<mailto:dr6...@att.com>>; TIMONEY, DAN 
<dt5...@att.com<mailto:dt5...@att.com>>; ZITELLA, MICHAEL V 
<mz1...@att.com<mailto:mz1...@att.com>>; DAUGHERTY, ROBERT E 
<rd4...

[onap-discuss] M4 Code Freeze Milestone Review

2017-09-15 Thread Yoav Kluger
Hi Gildas,

Noticed you have scheduled this review for Thursday - do we know that people 
will be staying for Thursday to attend this review?

Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278
[amdocs-a]

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 
<https://www.amdocs.com/about/email-disclaimer>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


Re: [onap-discuss] [integration][so] vCPE workflow discussion

2017-08-30 Thread Yoav Kluger
Gil,

Are you saying that what is still missing are the exact format of the object in 
A and the exact format of the event produced by A when this object is 
updated? Or do you see something more than that which we still need to work out?

Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278



_
From: BULLARD, GIL [mailto:wb5...@att.com]
Sent: Wednesday, August 30, 2017 5:49 PM
To: Kang Xi <kang...@huawei.com>; onap-discuss@lists.onap.org; DAUGHERTY, 
ROBERT E <rd4...@att.com>; Yoav Kluger <yoav.klu...@amdocs.com>
Cc: ZINNIKAS, MICHAEL J <mz2...@att.com>
Subject: RE: [integration][so] vCPE workflow discussion


Team,
I have updated the slides based upon the feedback today that modeling of BRG as 
a PNF will not be viable from an SO perspective in R1.  I have thus changed it 
to an Allotted Resource.  The updated slides can be found here:
https://wiki.onap.org/display/DW/Residential+Broadband+vCPE+Drafts+for+discussion?focusedCommentId=15991633=1504129602127#comment-15991633

Comments are appreciated.

One issue we need to work is exactly which object SDNC will update in A as 
part of the BRG Event processing flow, and what will the event look like that 
is intercepted by ROBOT.  We need to verify that Robot will be able to 
correlate this event.  I believe that this can be done because the event will 
have the BRG_EMU VNF UUID on it.
Thanks,
Gil


-Original Appointment-
From: Kang Xi [mailto:kang...@huawei.com]
Sent: Wednesday, August 30, 2017 10:44 AM
To: Kang Xi; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; 
DAUGHERTY, ROBERT E; BULLARD, GIL; KLUGER, YOAV
Subject: [integration][so] vCPE workflow discussion
When: Wednesday, August 30, 2017 1:30 PM-3:00 PM (UTC-05:00) Eastern Time (US & 
Canada).
Where: https://zoom.us/j/44





This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 
<https://www.amdocs.com/about/email-disclaimer>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


Re: [onap-discuss] vCPE: Consider multi-cloud support in R2

2017-08-10 Thread Yoav Kluger
Gaurav,

Performance and latency KPIs have not been defined for this use case, these 
will depend on the specific VNFs selected by each operator rather than ONAP as 
the MANO system.

But I do not see a reason why multiple instances of the vCPE service cannot be 
brought up. They will all be instantiated in the same DC, but will run 
separately.

Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278
[amdocs-a]

From: Gaurav Gupta (c) [mailto:guptagau...@vmware.com]
Sent: Wednesday, August 09, 2017 11:50 PM
To: Yoav Kluger <yoav.klu...@amdocs.com>; Kang Xi <kang...@huawei.com>
Cc: onap-discuss@lists.onap.org
Subject: Re: vCPE: Consider multi-cloud support in R2


Yoav , Kang Xi



if the below two are not goal



a.1- If performance  or latency on VxLAN is not being monitored and not the 
goal for individual  vCPE

a.2 - Also if multiple Instances of vCPE existing at the same time  is not to 
be supported



Then whether vCPE is  deployed across  multiple DC or single DC it makes no 
difference .Hence I would agree  to what is described below .



with best regards

gaurav




From: 
onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> 
<onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>>
 on behalf of Yoav Kluger 
<yoav.klu...@amdocs.com<mailto:yoav.klu...@amdocs.com>>
Sent: 10 August 2017 03:52:41
To: Kang Xi; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>
Subject: Re: [onap-discuss] vCPE: Consider multi-cloud support in R2


Kang, all,



Sorry could not attend the meeting (which collided with the ARC meeting).



I would propose to not view the connectivity between clouds as a problem, or 
use case, ONAP needs to solve. Service provides who have deployed multiple 
clouds have typically also established connectivity between them, in most cases 
via some type of a L2 VPN. When ONAP instantiates VNFs there is an assumption 
that it can then communicate with them, e.g. for configuration or closed loop 
operations, over an OAM overlay network. We do not bother showing how this OAM 
network is routed, and in particular how SDNC, as an example, can communicate 
with a VNF which happens to be instantiated in a remote DC. We assume whatever 
underlay is need is in place which allows communicating with all VNFs over the 
one OAM network.



Similarly, if two VNFs are assumed to communicate over regular IP networking 
(not to be confused with service chaining), then, without loss of generality, 
we can showcase them in one DC, assuming that if in real life they were to be 
instantiated in two DCs, then the inter-dc connectivity already in place would 
enable them to communicate just as well.



The other alternative would be that we would have to showcase each VNF in a 
separate DC - to "make sure" the use case works under any deployment scenario. 
This obviously does not make sense, and fortunately is also not needed for the 
reasons sated above.



I would therefore submit that the vCPE use case, which instantiates all its 
VNFs in a single DC, is sufficient to showcase ONAP's capability to instantiate 
and manage a vCPE use case under any deployment.



Thanks,

Yoav Kluger

Amdocs Technology

+1(201)912-7294

+972-54-4850278

[amdocs-a]



From: Kang Xi [mailto:kang...@huawei.com]
Sent: Tuesday, August 08, 2017 11:37 AM
To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>
Cc: Yunxia Chen <helen.c...@huawei.com<mailto:helen.c...@huawei.com>>; 
Pawłowski Michał 1 - Korpo 
<michal.pawlows...@orange.com<mailto:michal.pawlows...@orange.com>>; Yoav 
Kluger <yoav.klu...@amdocs.com<mailto:yoav.klu...@amdocs.com>>; FREEMAN, BRIAN 
D <bf1...@att.com<mailto:bf1...@att.com>>
Subject: vCPE: Consider multi-cloud support in R2



Hi All,



During the meeting "[integration] vCPE for R1: Support multiple clouds or not?" 
(Aug. 8 11:00-11:25am EST), the attendees unanimously concluded to leave the 
support for multiple clouds to the next release. For R1, the release 
implementation will only target a single cloud set up.



The rationale behind the above conclusion is that multi-cloud support, while 
technically feasible, would need quite some discussions to decide on multiple 
issues including lab set up, network set up, work flow design, etc. Adding it 
to R1 would further tighten the R1 schedule.



The list of attendees is shown below:



[cid:image005.jpg@01D311E7.A317A630]

Regards,

Kang


This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at 
https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer=DwMFBA=uilaK90D4TOVoH58JNXRgQ=ebJjFMpXijqZjbZCcbF7yJIq2ES6jM0Q-DEcP-qjjeI=92eKrYAeI78xAB

[onap-discuss] vCPE use case discussions: VNF onboarding, SDC and CLAMP - Follow-up

2017-07-05 Thread Yoav Kluger
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Israel Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=4FR;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Yoav Kluger:MAILTO:yoav.klu...@amdocs.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Kang Xi:MA
 ILTO:kang...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Yunxia Che
 n:MAILTO:helen.c...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Liuguangmi
 n:MAILTO:liuguang...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Liyifeng (
 liyifeng):MAILTO:lee.liyif...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Jon Fannar
  Karlsson Taylor:MAILTO:jon.tay...@amdocs.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'SPATSCHEC
 K, OLIVER  (OLIVER)'":MAILTO:spat...@research.att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Lingli De
 ng':MAILTO:denglin...@chinamobile.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Kenny Pau
 l':MAILTO:kp...@linuxfoundation.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Yang Xu (Y
 ang, Fixed Network)":MAILTO:yang@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'FREEMAN, 
 BRIAN D'":MAILTO:bf1...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'LEFEVRE, 
 CATHERINE'":MAILTO:cl6...@intl.att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'ROSE, DAN
 IEL V'":MAILTO:dr6...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=onap-discu
 s...@lists.onap.org:MAILTO:onap-discuss@lists.onap.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='wangcheng
 l...@chinamobile.com':MAILTO:'wangchen...@chinamobile.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='platania@
 research.att.com':MAILTO:'plata...@research.att.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='cc697w@in
 tl.att.com':MAILTO:'cc6...@intl.att.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='ac2550@in
 tl.att.com':MAILTO:'ac2...@intl.att.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='spondonde
 y...@att.com':MAILTO:'spondon...@att.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='ha076r@at
 t.com':MAILTO:'ha0...@att.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='vanbrakle
 @att.com':MAILTO:'vanbra...@att.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='xiaolong.
 k...@orange.com':MAILTO:'xiaolong.k...@orange.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='francois.
 desp...@orange.com':MAILTO:'francois.desp...@orange.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='yangyi.br
 i...@chinatelecom.cn':MAILTO:'yangyi@chinatelecom.cn'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Alla Goldn
 er:MAILTO:alla.gold...@amdocs.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Anatoly A
 ndrianov':MAILTO:anatoly.andria...@nokia.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Andrei Koj
 ukhov:MAILTO:andrei.kojuk...@amdocs.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Avi Chapni
 ck:MAILTO:avi.chap...@amdocs.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Eric Debe
 au':MAILTO:eric.deb...@orange.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='George La
 piotis':MAILTO:george.lapio...@ericsson.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Gil BULLA
 RD':MAILTO:wb5...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=denghui (L
 ):MAILTO:denghu...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Zengjiangu
 o (OSS Design):MAILTO:zengjian...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='John Zann
 os':MAILTO:jaazan...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Liron Shtr
 aichman:MAILTO:liron.shtraich...@amdocs.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Maopeng Z
 hang':MAILTO:zhang.maope...@zte.com.cn
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Mark Pond:
 MAILTO:mp...@amdocs.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Mazin Gil
 bert':MAILTO:ma...@research.att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Nagesha S
 ubramanya':MAILTO:nagesha.subrama...@nokia.com

[onap-discuss] Call for vCPE VNFs proposals

2017-05-31 Thread Yoav Kluger
Dear ONAP community,

As we all know, the Residential Broadband vCPE use case is one of our two 
targeted use cases for R1.
Its wiki 
page<https://wiki.onap.org/display/DW/Use+Case%3A+Residential+Broadband+vCPE> 
has been significantly enriched recently, and more details are added on a daily 
basis.
A general residential broadband solution can be much more complex than what 
would be reasonably achievable by R1. We have narrowed down the description of 
the use case for R1, to something that should be both achievable and usable.
For the use case to work the following VNFs will be needed:

* vBNG

* vHGW

* vDHCP

* vDNS

* vAAA


In addition a simple hardware box with 802.1ad capabilities will be needed.

This is a call for vendors of such VNFs and/or such a box to join the activity. 
Would be great if by Beijing time the wiki will have at least one vendor name 
alongside every VNF, and also at least one vendor for the box.

Thanks,
Yoav Kluger
Amdocs Technology
+1(201)912-7294
+972-54-4850278
[amdocs-a]

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 
<https://www.amdocs.com/about/email-disclaimer>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss