Subject: [hackathon] IETF98 OpenBMP projects added

From: "Tim Evens (tievens)" <[email-masked]>
Date: Mon, 13 Feb 2017 23:37:42 +0000

Hi, 

I recently added OpenBMP to the hackathon list.  Below are details for each of the project ideas. Is anyone interested?  Please let me know.  We can narrow this list or expand it based on interest. 

* Point-in-time peer snapshots with both machine and human readable diffs
    
   One of the most basic analysis is to compare two samples and report on the
   differences.   For example, peer RIB entries and all attributes for peer
   ABC at time A compared at time Z.  This very simple analysis has previously
   been overly complex and cumbersome for everyday use because the data has
   not been easily accessible in a format for comparison by average users.  
   Repeating this process as often as needed by multiple users normally results
   in things getting more complex and slow, making it even less likely to be
   used daily. 

   Some useful cases for peer snaphots are:
 
      - Change control/success validation - For example, upgrade router and
        ensure all peers come back as they were before the upgrade
      - Peer state change - Automatically monitor based on peer state-change
        notification and EoR that the expected NLRI's are present as compared
        to last snapshot.  For example, peer level policy change triggers an
        admin-config notification causing a reset. When peer comes back up, 
        NLRI's that were previously tagged with community 300:123 now contain
        an additional community of 300:300. Another example is when the
        notification indicates holdtime expire or admin-shut.   In this case
        the expected NLRI's for given category of peer might be to have the
        same prefixes as before.  If not, a diff would be provided. 
      - Historical snapshot to report on growth or change over time.   For
        example, report on prefix distribution from snapshot taken 6 months 
        ago. 

   In this project, we'll use OpenBMP manager application to initiate and
   consume snapshots to build various snapshotting/diff based applications.

* Alert on prefixes that match dynamic, adaptive, and/or static conditions

   Most network engineers and automated systems lack the ability to monitor
   real-time routing table changes.  There can be hundreds of millions of 
   routing table entries when considering the sum of all routers and 
   peers/neighbors. Detecting if a prefix shows up, such as a more specific,
   has been a non-trivial task.  The inverse is also equally important,
   such as when a more specific is lost.  

   Some useful cases for monitoring real-time changes are:
      - Watch list - Monitor for the presence or non-presence of specific
        prefixes or prefixes that match attributes, such as community or
        as_path.  For example, monitor anycast addresses to ensure they are
        always advertised by at least two diverse locations.   Another 
        example is to monitor prefixes by community string and ensure that
        at least X number of expected prefixes exist.
      - Configuration Errors and/or violations - Monitor prefix by peer
        and their associated attributes against one or more policies.  For
        example, 300:100 cannot be combined with 300:500.  This would be
        a policy violation.   
      - Route leak detection - Monitor new specifics or aggregates that
        that do not match origin from previous base line, RPKI and/or IRR
        origin, data. Detection of origin mismatch of exact, new specific
        or aggregate can be easy to do. Detection of a new transit is more
        complicated because a new transit may be just that. Alerting on
        only new transit is trivial, but will generate a lot of noise. 
        Instead the detection of new transit should take into consideration
        of the bigger picture to determine if the new transit is a leak 
        candidate.  For example, prefix A is always advertised with
        ASN's 200, 300, and 400 to the left of its ASN of 500. Then
        prefix A shows up with ASN 6000 to the left of ASN 500.  In 
        this case, ASN 6000 is a partner with ASN 500 and ASN 6000 made a
        mistake in advertising the private peering information, resulting
        in ASN 6000 becoming transit for ASN 500 prefix A. The same example
        scenario can happen further in the AS_PATH, such as when a transit
        provider accepts prefixes from another provider, resulting
        in a larger leak.  
    
    In this project, we'll use OpenBMP manager and live feeds to monitor BGP
    advertisements and withdrawals in real-time to build applications that
    monitor and alert on changes.

* Integrate BGP data with other data, such as geo-coding, RPKI, community 
  mappings, etc.

   BGP data by itself is can be quite limiting. DNS WHOIS, RPKI, IRR, 
   community to name or community to policy mappings, etc. enrich the 
   BGP data greatly.  This enrichment enables the ability to filter prefixes
   by category, policy, location, and more.   

   In this project, we'll leverage existing methods to enrich OpenBMP BGP 
   data with various external sources of data.  

Thanks,
Tim