Week 47 (NEX-008)
 
Present:
Filip Å (SE)
Jacob Dall (DK)
Kristian Skov (DK)
Magnus Bosson (NO / FIFTY)
Martin Edwin Schjødt Nielsen (DK)
Michael Rulle (DK)
Mika Niemi (FI / eSett)
Morten Simonsen (NO)
Thorbjørn Toft (DK)
Määttä Miika (FI)
Fedder Skovgaard (DK / guest)
 
Introduction of Michael and Marting -> welcome new NEX participants
 
TSO and other statuses:
Energinet:
Validating 4.7.1 versions in test. Some small issues noticed - investigation ongoing. Dashboard disappearing after the upgrade in some deployments. Energinet has kubernetes setup, so new docker deployment was done.  
 
SVK:
Firewalls opened to Fingrid and Energinet (sync in progress with Fingrid). 
Kafka setup done and messages sent through Kafka to Statnett.
 
Fingrid:
Sync to SVK pending
Preparing for 4.7.1. upgrade.
 
Statnett:
Production is stabile. Some issues in test network because of NBM. Central broker got stuck because the mass sending of messages. This causes delays of receiving messages. To be discussed later
 
RSC:
ECP network setup to the new network ongoing. A lot of ssl connection errors between components. Discussion that is JDK installation required instead of JRE to get connections working. Redhat version of the jre should be used. Once these issues are resolved, estimate of moving to the new network setup will be scheduled
 
eSett:
Test components are upgraded (4.7.1.) Prod upgrade later.
HA setup has been disabled due to issues. HA will be re enabled 14th of Dec with Unicorn.
 
eSett communication harmonization:
Roadmap for using ECP as the only channel in NBS presented. Rough schedule to have ECP as the only communication option 2022. TSO migration by the end of 2021. 
NEX should give a proposal if this schedule is realistic (biggest known risk is the high volume of messages). 
-> is NEX ready to scale up fast enough with high volume of messages.
->AP: NEX will come up with an analysis and proposal how to proceed….?
Then this should be presented to NMEG/NIT -> big impact to business side.
 
CSSg / ECCOSP 
(entsoe level ECP+EDX group). Fedder explained the work  that is being done in ENTSO-E level to investigate the usage of ECP+EDX  and benefits TSOs could have by using it.
ECP is using spring4 (which is end of life version). Moving to spring5 in next big release (before summer) will require a lot of effort from 
 
NMEG
No new updates from NMEG
 
 
EIC-V code usage:
Original proposal:
"
V-Code Policy Proposal
===================
1)            The V-code for an ECP-endpoint MUST be issued by the owner of the ComponentDirectory the ECP-endpoint will join
2)            The V-code MUST have the same prefix as the ComponentDirectory prefix (= country code + V)
 
The reasoning is as follows:
a)            This will avoid that any ECP-endpoint from two CDs will have the same code
b)           The V-code of the ECP-endpoint will immediately tell which CD it belongs to (no need to look up)
c)            Sorting of V-codes in lists will follow the CDs
d)           The actual physical location of an ECP-endpoint is not of any importance
"
Energinet / Fedder: Some participants in ECP network are not local participants. They have a code from their local EIC code issuing office. 
Discussion on should international participants request a code from international issuing office..? 
 
Discussion on how the ECP system should prevent registering an existing EIC code. Also it would be important that CD sync would not mess up the system in case a duplicate code exists in another CD.
AP: this will be discussed in the next NEX meeting -> goal to come up with a proposal how this should be handled.
 
Heartbeat / connectivity test
•	At the moment the suggested way to do this is to make a scheduled ping
o	Is there any better way to do this / propose how the product could handle this?
o	Monitoring would be seen useful.
o	AP: Morten to bring this up in CSSg
 
Network discussion
•	How to ensure the availability of NEM netowrk? E.g. DoS -attack? 
•	Should Nordic RPN network be used for critical communication? 
•	NEM availability should be presented?
o	E.g. NEM is vulnerable for large scale DoS attacks
o	Should the goal be 99.9% availability?
o	Should we have RSC network as a failover network for critical messages? 
o	AP: Morten - does FIFTY <-> TSO have known messages that cannot be relying on the public internet? If yes, then this topic is urgent.
 
Late arriving messages
•	Sometimes a message will arrive late. Is it possible to add rules for TTL of a certain MessageTYpe in ECP, to prevent an old message trigger an action. But should we do it?
o	Would this bring more configuration issues? In case nothing is done, then huge amount of messages might flood the network / brokers
o	Could throtling be used to prevent flooding?
o	NMB-Z35 time to live should be set in each endpoint in TSO
	This can se set in message types in ECP endpoint GUI. 
	AP everyone: set TTL to 30 sec for NBM-Z35