Sorry, your browser does not support JavaScript!

Homepage || F.A.Q. || Contact Us

Frequently Asked Questions

1. What is a Limited Visibility prefix?

2. Does limited visibility imply limited reachability?

3. Is a LVP always the result of a mistake/slip?

4. Which is the routing data use in the study?


  1. What is a Limited Visibility Prefix (LVP)?

    We define Limited Visibility Prefixes (LVPs) as prefixes that are not present in every routing table. We use the Visibility Scanner Algorithm to identify them.
    Countrariwise, we define the High Visibility Prefixes (HVPs) as prefixes that are present in almost all the routing tables.

    Based on the sample of full routing tables we analyze, we define a LVP as a prefix that appears in at most 95% of the sampled routing tables (e.g., for a sample of 100 different routing tables, if we find a prefix in less than 95 out of the 100 routing tables, it gets a LVP label).
    Contrariwise, if the prefix is present in at least 95% of routing tables, we label it as High Visibility Prefix (HV).


  2. Does limited visibility imply limited reachability?

    Limited visibility does NOT imply limited reachability. By definition, a Limited visibility prefix has a covering less-specific High Visibility Prefix which offers full reachability.
    However, there is subset of LVPs that are marked as Dark Prefixes (DPs). The DPs are defined as limited visibility prefixes wich are not covered by any less-specific prefix with global visibility (or a perfectly covering set of more-specific globally visible prefixes), as depicted in Fig. 1.
    This might mean that these dark prefixes might experience reachability issues in the absence of a default route.

    DP_vs_LVP

    Fig 1. The Dark Prefixes are LVPs without a covering HVP.



  3. Is a LVP always the result of a mistake/slip?

    Limited visibility prefixes can have many different causes. We had some initial talks with operators and discovered mis-configurations can be one of them, as well as the actions of third parties.
    However, some of the LVPs are intended to have limited visibility, and this happens as a consequence of the routing preferences of the origin AS.


  4. Which is the data we use for our analysis?

    We analyze the BGP routing information contained in all the full routing tables from all the Autonomous Systems which are a part of the RIPE NCC RIS and RouteViews projects.
    We retrieve on a daily basis all the routing tables from all the different active collectors. We use only the full routing feeds from the monitors within the networks participating in these projects. In order to avoid the transient routes, we analyze 2 different samples of the routing feeds taken 8 hours apart, eliminating the prefixes which do not consistently appear in the same routing tables in this time period. We further polish our data by eliminating bogons and martians, MOAS (multiple-origin AS) prefixes and internal routes (i.e. the prefixes present in only one routing table ans with an AS-path of length 1).

    For more information regarding the methodology, we refer the reader to the paper "The BGP Visibility Scanner", accepted for publication in Proceedings of 16th IEEE International Global Internet Symposium (GI 2013), with INFOCOM 2013.

    methodology

    Fig 2. The BGP Visibility Scanner methodology (you can enlarge the image by clicking on it).



  5. Top


    This is a joint project between Institute IMDEA Networks and the NETCOM Research Group from Univeristy Carlos III of Madrid, Spain.
    Please contact us if you have further questions or comments.