Thank you very much for arranging the meeting.
Unfortunately, I have not yet received site access approval.
For establishing a mini E2 site at RCNP, Osaka, here are the items
I would like to make clear, or ask you.
-
network connection for E2 sites,
I suppose the E2 sites must be within a closed network (L3VPN?).
If it is true, using LHCONE may be the best option, as Alexei told me
at the JLab mini-workshop.
-
Use of LHCONE
As shown in Hiro-san's slide, several Japanese institutes are connected
to the LHCONE network. But RCNP/Osaka is not connected.
If we use LHCONE for the E2 site connection, we have to bring it to our site.
I am managing the networking of RCNP, but personally, I have no experience
operating or managing the LHCONE connection. So I want to know what
we should do to join LHCONE.
It is also shown in Hiro-san's slide that the use of LHCONE is based on
specific projects (ATLAS, ALICE, Belle II,...etc). I do not know what level
of agreement or approval is required. Can we join LHCONE as a small
group (for example, "ePIC E2 Osaka")?
- Alternative options?
If the use of LHCONE at RCNP/Osaka is difficult or takes a long time. Are there
any alternative solutions?
Mark :
These are excellent questions, thank you for raising them. They’ll generate valuable discussion, so I’ll try to address a few of them here.
I believe placing the E2 sites within an L3VPN would simplify the overall architecture for data distribution. Joining LHCONE could be the easiest starting point since it’s already an established framework. However, as Hiro’s diagram shows, LHCONE has grown quite complex. It might be worth engaging ESnet (BNL’s/DOE’s research and education service provider) to discuss whether they would consider deploying a dedicated L3VPN for EIC in the long term, or if continuing within LHCONE makes more sense.
If you proceed with LHCONE, you’ll need to comply with their Acceptable Use Policies (AUP). I’m not certain whether EIC currently has permission to use LHCONE. For example, back in 2017–2018 when Belle-2 came to BNL, we had to justify and formally request permission to join LHCONE and LHCOPN. Looking ahead, EIC’s mission might not always align with LHCONE’s AUP, so a key strategic question is whether we want to manage our own L3VPN in the future — allowing us to define its purpose and control who can connect.
Regarding the management of LHCONE connections, this can get complex depending on your network architecture. LHCONE requires that you advertise only the subnets associated with collaboration resources, ensuring that general site traffic does not traverse the service. This may necessitate separate network infrastructure or more advanced routing designs, such as policy-based routing or segmented routing tables.
I’ve attached a high-level diagram of our current Network Perimeter to show how we address this challenge at BNL and avoid asymmetric routing.
As for alternatives I’m not sure but we can work with ESnet to try to identify a solution. Is the current goal to gain direct or better access to BNL for data transfers?
