Hello, Ben
Thanks for updating the text. A few more comments below in red.
By the way, Steven has some additional comments on the Jira
ticket page, which you may want to take into consideration as well.
Have a nice day
Zu Qiang
From: Cheung, Ben (Nokia - US/Murray Hill) <[email protected]>
Sent: Wednesday, September 19, 2018 12:02 PM
To: Zu Qiang <[email protected]>; WRIGHT, STEVEN A <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: RE: [onap-discussion]#vnfrqts#5G PnP: Updated Requirements
Zu Qiang,
Responses and updates in-line
-Ben
PNP-1330 [PNF] - The PNF Vendor MUST provide software Version(s) to be
supported by PNF for SDC Design Studio PNF Model. This is set in the PNF Model
property software_versions.
[Zu Qiang] In 5G PnP wiki page the sw-version is an optional parameter. It
cannot be a must requirement. “PNP-1100[SDC]: The user can (optional) provide
the following to define the resource definition…”
[BEN] Yes ok. Thanks.
PNP-1330 [PNF] - The PNF Vendor MAY (optional) provide software Version(s) to
be supported by PNF for SDC Design Studio PNF Model.
Note: This is set in the PNF Model property software_versions.
PNP-1340 [PNF] - The PNF MUST onboard the pnfRegistration VES Event, HVol VES
Event, and Fault VES Event.to be supported by the PNF into the SDC Design
Studio.
[Zu Qiang] How a PNF onboard a VES event using SDC design studio? What is
onboard means? Support? [BEN] – VES event definitions are onboarded with SDC
Design studio produces SDC artifact.
[Zu Qiang] “to be supported by the PNF into the SDC Design Studio.” Is this an
incomplete statement? [BEN] – corrected see below
[Zu Qiang] Proposed rewording: “The following VES events MUST be supported by
the PNF for ONAP PNF plug and play registration procedure: …”
[BEN] – clarifying …
PNP-1340 [PNF] - The following VES events MUST be supported by the PNF:
pnfRegistration VES Event, HVol VES Event, and Fault VES Event. These are
onboarded via the SDC Design Studio. Note: these VES Events are emitted from
the PNF to support PNF Plug and Play, High Volume Measurements, and Fault
events respectively.
[Zu Qiang] Clarification question: What does onboard mean? Do you mean at SDC
design studio, there are checkbox which needs to be clicked? Or forms which
needs to be filling-in?
PNP-3010 [PNF] - The PNF MUST 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.
[Zu Qiang] Can you keep the explanation text in a new line as you did in
PNP4410?
[Zu Qiang] Is it out of scope for ONAP to specify how the contact address is
provisioned. Please remove: “It is expected that an external EMS would
configure & provision the ONAP contact IP address to the PNF (in either IPv4 or
IPv6 format).” And the example. [BEN] – ok I have made these just “notes” now.
[BEN] – updated.
PNP-3010 [PNF] - The PNF MUST support & accept the provisioning of an ONAP
contact IP address (in IPv4 or IPv6 format).
Note: 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 the 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 to access ONAP.
[Zu Qiang] Please remove the statement “It is expected that an external EMS
would configure & provision the ONAP contact IP address to the PNF (in either
IPv4 or IPv6 format).”. it is not in the scope of ONAP.
PNP-3020 [PNF] - The PNF MUST have "ONAP Aware" software either installed, or
loaded that is capable of performing PNF PnP registration with ONAP. It is up
to the specific vendor to design the software management functions. The "ONAP
Aware" software that is capable of performing the PNF PnP Registration with
ONAP shall either be loaded separately or integrated into the PNF software upon
physical delivery and installation of the PNF.
[Zu Qiang] Does it make any difference to ONAP if the software is “installed”
or ‘loaded’? proposed rewording: “the PNF MUST have ONAP aware software to
perform ONAP PNF plug and play registration procedure.” [BEN] – whether
installed or loaded is particularly important during the PnP procedure. Because
there is also a ONAP S/W download use case in particularly is not used. So this
wording is important.
[Zu Qiang] Besides, the ONAP aware software capability has been explained
twice. [BEN] – No it isn’t. The first sentence says that this software must be
pre-installed or loaded by an operator or by a technician. The third sentence
defines what the ONAP aware software actually does.
[Zu Qiang] Please make the Note in a new line as you did on other requirements.
PNF-3030 [PNF] - The PNF MUST support the provisioning of security and
authentication parameters in order to be able to authenticate with DCAE (in
ONAP). In R3, a username and password are used with the DCAE VES Event Listener
which are used to authenticate a PNF. The configuration management and
provisioning software are specific to a vendor architecture, but the PNF shall
have the software to support configuration of identification information so
that a proper authentication exchange can happen with ONAP.
[Zu Qiang] “In R3 ..” is duplicated with PNP4120. Please remove it.
Rewording proposal: “the PNF MUST support the provisioning of security
parameters for ONAP authentication”
[BEN] – ok I have made that a note for you.
PNF-3030 [PNF] - The PNF shall support the provisioning of security and
authentication parameters in order to be able to authenticate with DCAE (in
ONAP).
[Zu Qiang] Please use MUST instead of SHALL.
Note: In R3, a username and password are used with the DCAE VES Event Listener
which are used to authenticate a PNF. The configuration management and
provisioning software are specific to a vendor architecture, but the PNF shall
have the software to support configuration of identification information so
that a proper authentication exchange can happen with ONAP.
[Zu Qiang] the Note is overlapped with PNP4120
PNP-4120 [PNF] - The PNF MUST 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).
[Zu Qiang] This is what is specified in VES 7.0.1 “In the future, support for
2-way SSL certificate authentication (aka mutual SSL) will be provided but for
now, event source credentials are passed using HTTP Basic
Authentication<http://tools.ietf.org/html/rfc2617>.”
Propose using the same language. “PNF must support HTTP Basic
Authentication<http://tools.ietf.org/html/rfc2617> as specified in VES 7.0.1…”
[BEN] – HTTP Basic Authentication is a 4-step process composed of HTTP Request,
Authenticate, Authorization with Credentials, Authentication Status info
response. This 4-step process is not specified in VES 7.0.1 but rather RFC 7617
and RFC 2617.
PNP-4120 [PNF] - The PNF MUST 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). The PNF
MUST use Basic HTTP Authentication (Request, Authenticate, Authorization with
Usename/Password Credentials, and Authentication Status) as per RFC7617 and RFC
2617.
[Zu Qiang] let me try this again.
In ONAP security recommendation page, there are three ways for DCAE auth of a
NF which is already supported in Casablanca:
* usr/pwd over HTTP (no TLS)
* usr/pwd over HTTP/TLS with server side certificate
* usr/pwd over HTTP/TLS with two way certificate
Your text disallows what is already supported in Casablanca.
By the way, this is a common requirement on both VNF and PNF. Therefore it
shall be a requirement on “xNF”.
PNP-4200 [PNF] – The PNF MUST 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.
[Zu Qiang] In VES 7.0.1, “HTTPS (rather than HTTP) should be used.” So HTTPS is
a SHOULD requirement. HTTP is allowed but not recommended.
[Zu Qiang] Please remove “previously”
[BEN] – ok
PNP-4200 [PNF] – The PNF MUST use a provisioned IP address to contact ONAP. The
PNF SHOULD open a HTTPS connection to the DCAE VES Event Listener.
[Zu Qiang] My propose is to split this requirement into three:
* The PNF MUST use a provisioned IP address to contact ONAP.
* The PNF SHOULD support HTTPS connection to the DCAE VES Event Listener.
* The PNF MAY support HTTP 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.
Note: HTTP is allowed but not recommended.
PNP-4210 [PNF] – The PNF MUST send the pnfRegistration VES event.
[Zu Qiang] I guess you want to say “PNF must support sending ….”
[BEN] – ok
PNP-4210 [PNF] – The PNF MUST support sending a pnfRegistration VES event.
PNP-4410 [PNF] The PNF MUST continue to periodically send the pnfRegistration
VES event. The pnfRegistration VES event shall be sent with a configurable
periodicity.
[Zu Qiang] Proposed rewording: “the pnfRegistration VES event SHOULD be sent by
PNF 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.
[BEN] – ok
PNP-4410 [PNF] The PNF MUST continue to periodically send the pnfRegistration
VES event. The pnfRegistration VES event SHOULD be sent with a configurable
periodicity.
[Zu Qiang] My propose is to split this requirement into two:
* The PNF MUST send the pnfRegistration VES event periodically.
* The periodicity for sending the pnfRegistration VES event SHOULD be
configurable.
Note: The PNF uses the service configuration request as a semaphore to stop
sending the pnfRegistration sent. See the requirement PNP-5360 requirement.
PNP-4420 [PNF] - If the PNF encounters an error authenticating, reaching the
ONAP DCAE VES Event listener or receives an error response from sending the
pnfRegistration VES Event, it MUST 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.
[Zu Qiang] “log” and “notify” is an implementation choice. It cannot be a
“MUST” requirement. Please make it a “MAY”
[BEN] – ok
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 MAY 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 MUST support a Service Configuration message exchange
from the PNF Controller (in ONAP). 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.
[Zu Qiang] Supporting the message exchange does not mean anything. For
instance, an implementation can receive the message and do nothing. The
requirement should say when receiving the message, what action should be taken
by the implementation. Or what protocol should be enabled in order to receive
that message.
Propose rewording: “the PNF MUST support Ansible protocol for service
configuration from ONAP”
[BEN] – ok
PNP-5350 [PNF] - The PNF shall support the Anible protocol for a Service
Configuration message exchange between the PNF and PNF Controller (in ONAP).
[Zu Qiang] Please use MUST instead of SHALL.
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-5360 [PNF] - When the PNF receives a Service configuration from ONAP, the
PNF MUST cease sending the pnfRegistration VES Event.
PNP-5370 [PNF] - The PNF may support the optional parameters for the Service
Configuration Parameters for Stage 5 PnP 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.
[Zu Qiang] please remove “Stage 5” or move it into a note.
[BEN] ok
PNP-5370 [PNF] - The PNF MAY support the optional parameters for Service
Configuration Parameters.
Note: These are detailed in the Stage 5 PnP
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 MUST log the error and notify
an operator.
[Zu Qiang] “log” and “notify” is an implementation choice. It cannot be a
“MUST” requirement. Please make it “MAY”
[BEN] ok
PNP-5380 [PNF] (Error Case) - If an error is encountered by the PNF during a
Service Configuration exchange with ONAP, the PNF MAY log the error and notify
an operator.
PNP-5390 [PNF] (Error Case) - If the PNF never receives a Service Configuration
message from ONAP, it MUST 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.
[Zu Qiang] Proposed rewording: “The PNF must support a configurable timer to
stop the periodicity sending of the pnfRegistration VES event” [BEN] – I get
the idea, updating …
[Zu Qiang] it is hard to determine what is ‘never’ for an implementation. A
configurable timer is more precise. [BEN] – point taken.
[Zu Qiang] “log” and “notify” is an implementation choice. It cannot be a
“MUST” requirement. Please make it “MAY” [BEN] – ok
[Zu Qiang] the Note is repeated with 4410. Please either remove it or move it
into a generic place. [BEN] – there is no overlap
[BEN] – ok
PNP-5390 [PNF] (Error Case) - The PNF must support a configurable timer to stop
the periodicity sending of the pnfRegistration VES event. If this timer expires
during a Service Configuration exchange between the PNF and ONAP, it MAY log a
time-out error and notify an operator.
Note: It is expected that each vendor will enforce and define a PNF service
configuration timeout period. This is because 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.
Best regards,
-Ben Cheung, PhD, DMTS, ALTA
ATF Architecture Systems Engineer
Mobile Networks, Nokia
Tel +1 (908) 679-6615
Email [email protected]<mailto:[email protected]>
600-700 Mountain Ave, Murray Hill, NJ 07974-0636 USA / #2C-378
From: Zu Qiang [mailto:[email protected]]
Sent: Friday, September 14, 2018 12:07 PM
To: Cheung, Ben (Nokia - US/Murray Hill)
<[email protected]<mailto:[email protected]>>; WRIGHT, STEVEN A
<[email protected]<mailto:[email protected]>>
Cc: '[email protected]'
<[email protected]<mailto:[email protected]>>
Subject: [onap-discussion]#vnfrqts#5G PnP: Updated Requirements
Thanks Ben for updating the PNF requirements. Please see my comments inline
below.
Have a nice day
Zu Qiang
PNP-1330 [PNF] - The PNF Vendor MUST provide software Version(s) to be
supported by PNF for SDC Design Studio PNF Model. This is set in the PNF Model
property software_versions.
[Zu Qiang] In 5G PnP wiki page the sw-version is an optional parameter. It
cannot be a must requirement. “PNP-1100[SDC]: The user can (optional) provide
the following to define the resource definition…”
PNP-1340 [PNF] - The PNF MUST onboard the pnfRegistration VES Event, HVol VES
Event, and Fault VES Event.to be supported by the PNF into the SDC Design
Studio.
[Zu Qiang] How a PNF onboard a VES event using SDC design studio? What is
onboard means? Support?
[Zu Qiang] “to be supported by the PNF into the SDC Design Studio.” Is this an
incomplete statement?
[Zu Qiang] Proposed rewording: “The following VES events MUST be supported by
the PNF for ONAP PNF plug and play registration procedure: …”
PNP-3010 [PNF] - The PNF MUST 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.
[Zu Qiang] Can you keep the explanation text in a new line as you did in
PNP4410?
[Zu Qiang] Is it out of scope for ONAP to specify how the contact address is
provisioned. Please remove: “It is expected that an external EMS would
configure & provision the ONAP contact IP address to the PNF (in either IPv4 or
IPv6 format).” And the example.
PNP-3020 [PNF] - The PNF MUST have "ONAP Aware" software either installed, or
loaded that is capable of performing PNF PnP registration with ONAP. It is up
to the specific vendor to design the software management functions. The "ONAP
Aware" software that is capable of performing the PNF PnP Registration with
ONAP shall either be loaded separately or integrated into the PNF software upon
physical delivery and installation of the PNF.
[Zu Qiang] Does it make any difference to ONAP if the software is “installed”
or ‘loaded’? proposed rewording: “the PNF MUST have ONAP aware software to
perform ONAP PNF plug and play registration procedure.”
[Zu Qiang] Besides, the ONAP aware software capability has been explained twice.
PNF-3030 [PNF] - The PNF MUST support the provisioning of security and
authentication parameters in order to be able to authenticate with DCAE (in
ONAP). In R3, a username and password are used with the DCAE VES Event Listener
which are used to authenticate a PNF. The configuration management and
provisioning software are specific to a vendor architecture, but the PNF shall
have the software to support configuration of identification information so
that a proper authentication exchange can happen with ONAP.
[Zu Qiang] “In R3 ..” is duplicated with PNP4120. Please remove it.
Rewording proposal: “the PNF MUST support the provisioning of security
parameters for ONAP authentication”
PNP-4120 [PNF] - The PNF MUST 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).
[Zu Qiang] This is what is specified in VES 7.0.1 “In the future, support for
2-way SSL certificate authentication (aka mutual SSL) will be provided but for
now, event source credentials are passed using HTTP Basic
Authentication<http://tools.ietf.org/html/rfc2617>.”
Propose using the same language. “PNF must support HTTP Basic
Authentication<http://tools.ietf.org/html/rfc2617> as specified in VES 7.0.1…”
PNP-4200 [PNF] – The PNF MUST 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.
[Zu Qiang] In VES 7.0.1, “HTTPS (rather than HTTP) should be used.” So HTTPS is
a SHOULD requirement. HTTP is allowed but not recommended.
[Zu Qiang] Please remove “previously”
PNP-4210 [PNF] – The PNF MUST send the pnfRegistration VES event.
[Zu Qiang] I guess you want to say “PNF must support sending ….”
PNP-4410 [PNF] The PNF MUST continue to periodically send the pnfRegistration
VES event. The pnfRegistration VES event shall be sent with a configurable
periodicity.
[Zu Qiang] Proposed rewording: “the pnfRegistration VES event SHOULD be sent by
PNF 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-4420 [PNF] - If the PNF encounters an error authenticating, reaching the
ONAP DCAE VES Event listener or receives an error response from sending the
pnfRegistration VES Event, it MUST 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.
[Zu Qiang] “log” and “notify” is an implementation choice. It cannot be a
“MUST” requirement. Please make it a “MAY”
PNP-5350 [PNF] - The PNF MUST support a Service Configuration message exchange
from the PNF Controller (in ONAP). 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.
[Zu Qiang] Supporting the message exchange does not mean anything. For
instance, an implementation can receive the message and do nothing. The
requirement should say when receiving the message, what action should be taken
by the implementation. Or what protocol should be enabled in order to receive
that message.
Propose rewording: “the PNF MUST support Ansible protocol for service
configuration from ONAP”
PNP-5360 [PNF] - When the PNF receives a Service configuration from ONAP, the
PNF MUST cease sending the pnfRegistration VES Event.
PNP-5370 [PNF] - The PNF may support the optional parameters for the Service
Configuration Parameters for Stage 5 PnP 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.
[Zu Qiang] please remove “Stage 5” or move it into a note.
PNP-5380 [PNF] (Error Case) - If an error is encountered by the PNF during a
Service Configuration exchange with ONAP, the PNF MUST log the error and notify
an operator.
[Zu Qiang] “log” and “notify” is an implementation choice. It cannot be a
“MUST” requirement. Please make it “MAY”
PNP-5390 [PNF] (Error Case) - If the PNF never receives a Service Configuration
message from ONAP, it MUST 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.
[Zu Qiang] Proposed rewording: “The PNF must support a configurable timer to
stop the periodicity sending of the pnfRegistration VES event”
[Zu Qiang] it is hard to determine what is ‘never’ for an implementation. A
configurable timer is more precise.
[Zu Qiang] “log” and “notify” is an implementation choice. It cannot be a
“MUST” requirement. Please make it “MAY”
[Zu Qiang] the Note is repeated with 4410. Please either remove it or move it
into a generic place.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12522): https://lists.onap.org/g/onap-discuss/message/12522
Mute This Topic: https://lists.onap.org/mt/25675418/21656
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
