Latest Operations Minutes from Michael

LHCONE Operations Call (Notes: M. O’Connor)

January 5, 2015



Patrick Dorn

Roy Hockett

Bruno Hoeft

Joe Mambretti

Edoardo Martelli

Shawn McKee

Mike O’Connor

Luca Rinaldi

Mike Robbins


The BGP community based prefix filtering capability in LHCONE will be referred to simply as “BGP Filtering”, within the LHCONE networking context. This more generic term permits some expansion to other specific types of BGP filtering if necessary and presently there are no exclusive forms of LHCONE BGP filtering that require any distinction. Recommended by J. Mambretti.


LHCONE “BGP Filtering” is required to be implemented by participating NSPs but not required to be employed by “compute centers” or “sites”. Once implemented a site acts on it’s own behalf to affect redistribution of the sites own BGP route prefixes by the remote end NSP as defined by the LHCONE collaboration.


M. O’Connor will distribute an updated test plan to those participating in the BGP filtering tests. To participate in the tests please send an email indicating interest in “BGP Filter Testing” to


M. Robbins commented on the high degree of similarity between the filtering services that I2 provides on it’s general Internet service when compared to the LHCONE service and will check for supporting documentation that could be of use to LHCONE.


E. Martelli suggested that we discuss the elimination of the 65011:0000 community that prevents advertisement to any Tier 1 compute center.


  • High risk of routing asymmetry at network edges, with potential packet loss.

  • The term “Tier 1” is too broadly defined and can vary based on scope.

  • “Tier 1” does not provide the detailed information required by a site to successfully filter on import.

  • There are no commonly agreed to LHCONE BGP communities defined to distinguish “Tier 1” prefixes and no policy to require their use.


The potential for packet loss exists when LHCONE is used in one direction and the general Internet path is used in the other. So, the BGP filtering site must also reject in symmetric fashion the “target ASN” BGP route prefixes provided to it. For example, if ASN X employs “BGP Filtering” to prevent the remote side NSP from advertising their prefixes to ASN Y, then ASN X must also take care to reject all ASN Y prefixes it receives from it’s LHCONE NSP. This is problematic when using a filter that broadly affects all “Tier 1” compute centers due to the previously enumerated issues. This issue will be discussed at the February meeting in Cambridge, UK.


E. Martelli noted that Purdue University contacted CERN for LHCONE assistance and M. Robbins (I2) agreed to follow up.


Submitted by David Foster on Tue, 01/06/2015 - 15:15