Subject: Re: [hackathon] IETF98 OpenBMP projects added

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 17 Feb 2017 21:38:11 +0000

Tim,

This looks great. Thanks for brining OpenBMP to the hackathon. 
Do you anticipate there being physical network gear that would require wired Ethernet access to the IETF network? 
Would it be possible and worthwhile to try to pull information from the IETF network and run analyses on it?

Thanks again,
Charles

-----Original Message-----
From: hackathon <[email-masked]> on behalf of "Tim Evens (tievens)" <[email-masked]>
Date: Monday, February 13, 2017 at 6:37 PM
To: "[email-masked]" <[email-masked]>
Subject: [hackathon] IETF98 OpenBMP projects added

    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

    _______________________________________________
    hackathon mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/hackathon

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Thu, 23 Feb 2017 18:04:13 +0000

Hi Charles,

I don't expect any physical equipment needed.  Wireless internet access (>= 1Mbps) would be sufficient.   Is that going to be available?  The plan is to use MRT data files as the input data source.   I will also have my remote lab available where we can get live data feeds.   I can come with MRT data files already, so worst case we could work without Internet access. 

What does the IEFT network contain in terms of equipment?   If it's there, then it might be cool to enable BGP and IGP (ISIS and/or OSPF) monitoring of it.   

Thanks,
Tim

We can pull in MRT data and use that. I also have a live lab with Cisco and Juniper gear that we can access remotely.   The

On 2/17/17, 1:38 PM, "Charles Eckel (eckelcu)" <[email-masked]> wrote:

    Tim,

    Thanks again,
    Charles
    
    -----Original Message-----
    From: hackathon <[email-masked]> on behalf of "Tim Evens (tievens)" <[email-masked]>
    Date: Monday, February 13, 2017 at 6:37 PM
    To: "[email-masked]" <[email-masked]>
    Subject: [hackathon] IETF98 OpenBMP projects added
    
        Hi, 

            

        

            

        Thanks,
        Tim

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 24 Feb 2017 11:30:31 +0000

The wifi in the hackathon area is the same as the rest of the IETF meeting. Is it generally pretty good and high bandwidth because not too many people are on it yet on Saturday or Sunday. That said, there can be some hiccups because everything is still being setup and brought up. I am checking to see who we can talk to regarding access to live data feeds from the IETF network. That would be cool. 

Cheers,
Charles

-----Original Message-----
From: "Tim Evens (tievens)" <[email-masked]>
Date: Thursday, February 23, 2017 at 7:04 PM
To: Charles Eckel <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [hackathon] IETF98 OpenBMP projects added

    Hi Charles,

    
    Thanks,
    Tim

    
        Tim,

        Thanks again,
        Charles
        
        -----Original Message-----
        From: hackathon <[email-masked]> on behalf of "Tim Evens (tievens)" <[email-masked]>
        Date: Monday, February 13, 2017 at 6:37 PM
        To: "[email-masked]" <[email-masked]>
        Subject: [hackathon] IETF98 OpenBMP projects added
        
            Hi, 

                

            

                

            Thanks,
            Tim