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) <ben.che...@nokia.com> Sent: Wednesday, September 19, 2018 12:02 PM To: Zu Qiang <zu.qi...@ericsson.com>; WRIGHT, STEVEN A <sw3...@att.com> Cc: 'onap-discuss@lists.onap.org' <onap-discuss@lists.onap.org> 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 ben.che...@nokia.com<mailto:ben.che...@nokia.com> 600-700 Mountain Ave, Murray Hill, NJ 07974-0636 USA / #2C-378 From: Zu Qiang [mailto:zu.qi...@ericsson.com] Sent: Friday, September 14, 2018 12:07 PM To: Cheung, Ben (Nokia - US/Murray Hill) <ben.che...@nokia.com<mailto:ben.che...@nokia.com>>; WRIGHT, STEVEN A <sw3...@att.com<mailto:sw3...@att.com>> Cc: 'onap-discuss@lists.onap.org' <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> 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: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-