Week 50 (NEX-009) Present: Flemming Thejlman Bruun (DK / NRSC) Harju Matti (FI) Jacob Dall (DK) Magnus Bosson (SE) Martin Edwin Schjødt Nielsen (DK) Michael Rulle (DK) Mika Niemi (FI / eSett) Morten Simonsen (NO) Ove Morten Stalheim (NO) Thorbjørn Toft (DK) Are Torgersen (NO) Määttä Miika (FI) Filip Å (SE) TSO and other statuses: Energinet: 4.7.2 / 1.8.2 patch release testing in progress. At the moment. Performance of the 1.8.2 has improved significanlty. Still an issue when searching messages from the inbox with a filter through amqp. After a while toolbox freezes and messages are not received. Tested by sending a message and reading from the receiver side. At some point receiving side doesn't receive messages even the queue is empty. Sync between SVK/EN issue with CA certificates expiration date is too far. MySQL DB has invalid column type that cannot store the timestamp. Can be fixed by changing a column type. To be confirmed that can service restart change the column back. SVK: Testing with Fortum / firewall opening to service catalogue is not open. One other party is not able to receive messages from the broker (publishing works). Other endpoints are working. Preparing for connecting Fingrid / eSett with ECP Sync with FG/SVK done in test. Fingrid: Central components upgraded to 4.7.1. In progress of getting endpoints upgraded. Perhaps we will wait for 4.7.2 Preparing for connecting Fingrid / eSett with ECP Sync with SVK done in test. Statnett: Test side in 4.7.2 (Service Catalogue + central components). Everything seems ok. Issues with Java updgrade. Reason seems to be installing components in wrong version. If the correct order is followed, evetything seems to be ok. Upgrade guide should have the correct order of steps. When large number of diles processed, there has been issues. But seems tomcat related / not 4.7.2. Java version upgrade issues should be ok now. Java 8 version 272 caused issues. NRSC: Setting up test env in progress to Azure Stack. Preprod should be ready in the beginning of January. TSOs will be communicated with details later. JRE had issues with certificates. JDK worked fine. Certificate issues occurred in test setup. Certificats needed to be included in edx keystore. Unicorn helped with issues. Getting support agreement with Unicorn in progress. FG and Statnett connection to preprod broker stopped working. Endpoints had to be restarted. eSett: HA setup testing starting with Energinet next week. Plan is to test that number of sent messages matches with the received. Unicorn will investigate if HA is useful or not. Energinet 2nd step of NBS model go live in Feb. Plan to start receiving TSO messages from Fingrid. Also BRB side has possible pilot participants. Elhub communication ongoing with Morten/Statnett. Elhub is planning to start using ECP Q2/Q3 2021. The effort to start using ECP should not be big and plan is to try to push Elhub to start using sooner if possible. Notes from last meeting: " 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. " NBM Messages from all TSOs are received. ACE OL messages are empty from SVK (due to security issues / not prod data allowed) It is unclear that what messages TSOs are allowed to send from security perspective. About double amount of messages will be sent when all TSOs are sending all messges with the correct frequence. Should there be a TSO specific IG (implementation guide) that tells details for TSOs how to setup ECP communication (Are will investigate further) NBM - Network failover discussion Failover situation: • How to prepare if NEM is under a large scale Ddos attack? • The network and opeartional functionality can work without CD for a certain time. Broker is the most important part. o Could a separate broker be included in Nordic RPN network as a failover broker? NATed and not exposed externally o ECP message path routing doesn't support that at the moment -> question to Unicorn is sent related to this / Morten is handling this communication. If Unicorn cannot build this then the discussion below could be the only option: • Broker url options should be investigated • Backup options in case above cannot be achieved: o At the moment this could be solved by setting up separate endpoints in TSO. The failover endpoint would be connected to RPN network Broker by message path. o Broker connected to enet (statnett controlled private network). It is used ELCOM / ICCP? protocol communication • Thoughts / possible ideas besides above: o EDX service could have a primary and seconrady carrier/path? EDX layer doesn't define paths / broker to be used. o Message path / broker could be defined by messagetype (int platform could switch message type)  This would not require an additional endpoint o In failover situation messages might be lost when switch to failover channel is done AP: Morten and Ove Morten to investigate options on how to resolve this issue CSSg / ECCOSP ECP Backlog items are being groomed weekly by Morten and Jacob. Nordics are aiming to use ECP platform to (almost)all communication. Entso is thinking this more of a project specific way to communicate - e.g. project decides to use ECP or not / it is not defacto way of communicating. 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. This thing will not be concluded at the moment / perhaps will be revisited later. 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 o NEX 009 meeting: This will be proposed and followed up. This will be coming earliest 2022 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 Terms of use agreement when participating NEM Statnett has a terms of use agreement which was reviewed AP: Morten will share Statnett's document AP: each TSO representative should discuss about this within their TSO and let's revisit this next time.