Hello, Steven
The following is my comment on the Jira page which no response
is received yet.
hello, Benjamin
Cheung<https://jira.onap.org/secure/ViewProfile.jspa?name=bencheung>, Thanks
for updating the requirements text.
I have some general comments here:
* Is the requirements list in your comment the revised requirements
only? You can move the proposed text into description section to avoid
confusion.
* Please use the normative text "MUST", "SHOULD", "MAY" as requested in
section 3
* The reference to the 5G PnP wiki page must be removed. The 5G PnP
wiki has too many non-normative text.
* Any requirements beyond Casablanca release must be removed. If we
believe the function will be implemented in Dublin, we can keep the
requirements in a new Jira tickets in backlog.
* We should keep the normative text only and remove all the explanation
text in the notes. If anyone would like to have a better understanding on how
the 5G PnP works, he/she should read the 5G PnP wiki page.
I'll come back with some detail rewording proposals if we can have an agreement
on the general part first.
Have a nice day
Zu Qiang
From: Cheung, Ben (Nokia - US/Murray Hill) <ben.che...@nokia.com>
Sent: Tuesday, September 04, 2018 2:02 PM
To: WRIGHT, STEVEN A <sw3...@att.com>; 'onap-discuss@lists.onap.org'
<onap-discuss@lists.onap.org>
Cc: Zu Qiang <zu.qi...@ericsson.com>
Subject: RE: #vnfrqts PNP text
Steven,
I have addressed all of the comments received.
I have annotated the Jira w/ the latest text.
Here it is in consolidated form for you again:
(note boxes in Grey are unchanged from their initial version)
PNP-1320 [PNF] - [FUTURE R4] The PNF Vendor shall provide a PNF Descriptor for
Design time SDC Design Studio input based on ETSI-NFV-IFA014v242 (see
5G-PNFPlugandPlay-STAGE1-PNFDESCRIPTOR for more details)
Updated with direct URL links to the sections in the Wiki (and removed the
phrases "of this wiki page/document)
PNP-3010 [PNF] - The PNF shall support & accept the provisioning of an ONAP
contact IP address (in IPv4 or IPv6 format). It is expected that an external
EMS would configure & provision the ONAP contact IP address to the PNF (in
either IPv4 or IPv6 format). For PNF Plug and Play Use Case, this IP address is
the service provider's "point of entry" to the DCAE VES Listener. Note:
different service provider's network architecture may also require special
setup to allow an external PNF to contact the ONAP installation. For example,
in the AT&T network a maintenance tunnel is used.
PNP-4120 [PNF] - The PNF shall authenticate with the DCAE VES Event Listener
using a X.509v3 Certificate (issued by the Service Provider CA) also a username
and password (that had been previously provisioned and configured).
PNP-4200 [PNF] - The PNF shall use a previously provisioned IP address to
contact ONAP. The PNF shall open a HTTPS connection to the DCAE VES Event
Listener. Note: it is expected that an ONAP operator can ascertain the ONAP IP
address or the security gateway to reach ONAP on the VID or ONAP portal GUI.
Note: The ONAP contact IP address has been previously configured and
provisioned prior to this step.
PNP-4210 [PNF] - The PNF shall send the pnfRegistration VES event detailed in
the "PNF Registration VES Event" section of the Plug and Play wiki page at:
5G-PNFPlugandPlay-STAGE3-PNFREGISTRATIONVESEVENT
PNP-5390 [PNF] (Error Case) - If the PNF never receives a Service Configuration
message from ONAP, it shall time-out, log an error and notify an operator (if
possible). Note: It is expected that each vendor will enforce a PNF timeout
period, the PNF cannot wait indefinitely as there may also be a technician
on-site trying to complete installation & commissioning. The management of the
VES event exchange is also a requirement on the PNF to be developed by the PNF
vendor.
PNP-4420 [PNF] - If the PNF encounters an error authenticating, reaching the
ONAP DCAE VES Event listener or recieves an error response from sending the
pnfRegistration VES Event, it shall log the error, and notify the operator.
Note: the design of how errors are logged, retrieved and reported will be a
vendor-specific architecture. Reporting faults and errors is also a vendor
specific design. It is expected that the PNF shall have a means to log an error
and notify a user when a fault condition occurs in trying to contact ONAP,
authenticate or send a pnfRegistration event.
PNP-5350 [PNF] - The PNF shall support a Service Configuration message exchange
from the PNF Controller (in ONAP). Note: this exchange may be either Ansible,
Chef, or NetConf depending on the PNF. Note: The PNF Controller may be VF-C,
APP-C or SDN-C based on the PNF and PNF domain. Note: for R3 (Casablanca) only
Ansible is supported.
PNP-4410 [PNF] The PNF shall continue to periodically send t
he pnfRegistration VES event. The pnfRegistration VES event shall be sent with
a configurable periodicity.
Note: The PNF uses the service configuration request as a semaphore to stop
sending the pnfRegistration sent. See the requirement PNP-5360 requirement.
Note: It is expected that each vendor will enforce some sort of PNF timeout
period, the PNF cannot wait indefinitely as there may also be a technician
on-site trying to complete installation & commissioning. The management of the
VES event exchange is also a requirement on the PNF to be developed by the PNF
vendor.
PNP-5370 [PNF] - The PNF may support the optional parameters as detailed in the
Service Configuration Parameters detailed in the Stage 5 PnP Use Case at:
5G-PNFPlugandPlay-STAGE5-PNFACTIVATIONREQUIREMENTS Note: These parameters are
optional, and not all PNFs will support any or all of these parameters, it is
up to the vendor and service provider to ascertain which ones are supported up
to an including all of the ones that have been defined. Note: It is expected
that there will be a growing list of supported configuration parameters in
future releases of ONAP.
PNP-5380 [PNF] (Error Case) - If an error is encountered by the PNF during a
Service Configuration exchange with ONAP, the PNF shall log the error and
notify an operator.
Best regards,
-Ben Cheung, PhD, DMTS, ALTA
ATF Architecture Systems Engineer
Mobile Networks, Nokia
Tel +1 (908) 679-6615
Email ben.che...@nokia.com<mailto:ben.che...@nokia.com>
600-700 Mountain Ave, Murray Hill, NJ 07974-0636 USA / #2C-378
From: WRIGHT, STEVEN A [mailto:sw3...@att.com]
Sent: Tuesday, September 04, 2018 1:43 PM
To: 'onap-discuss@lists.onap.org'
<onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>
Cc: Cheung, Ben (Nokia - US/Murray Hill)
<ben.che...@nokia.com<mailto:ben.che...@nokia.com>>; Zu Qiang
<zu.qi...@ericsson.com<mailto:zu.qi...@ericsson.com>>
Subject: #vnfrqts PNP text
I wanted to followup on VNFRQTS-289<https://jira.onap.org/browse/VNFRQTS-289>
to see where the discussion is at. We've had a few comments, but I'm wondering
if there is a consolidated proposal version likely to appear this week ?
best regards
Steven Wright, MBA, PhD, JD.
[Tech Integration]
AT&T Services Inc.
1057 Lenox Park Blvd NE, STE 4D28
Atlanta, GA 30319
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12229): https://lists.onap.org/g/onap-discuss/message/12229
Mute This Topic: https://lists.onap.org/mt/25179061/21656
Mute #vnfrqts: https://lists.onap.org/mk?hashtag=vnfrqts&subid=2740164
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
