Hello opsawg, I spoke to a number of IETF folks at IETF 105, along with Tianran and Ignas (who I thank for their feedback and suggestions), and it was decided that opsawg would be the best place to at least start the conversations about a new draft I am proposing, as detailed below.
I document several use cases in the draft, but the short version is we are wanting to standardize a method for different vendors to handle ASIC-level replication of packets, to a remote server, including any and all information that ASIC may have about the packet, along with at least part of the payload, with a configurable sampling rate and filtering capabilities. Some things on my TODO list for it still: 1. I want to take a closer look at Flowspec rule definition, and see if that can be adequately encoded here. It looks like the YANG model for Flowspec rules was draft-wu-idr-flowspec-yang-cfg but that has since expired. 2. I'm planning on talking at NANOG 77 in Austin with other operators to see if there's additional use cases and how much appetite there is. 3. I'm talking with a couple vendors about implementations - there is interest here about it as well. I am sending out the -00 version of this draft and very much welcome comments and feedback. Thanks Andrew Gray On 8/5/19, 8:36 AM, "[email protected]" <[email protected]> wrote: A new version of I-D, draft-gray-sampled-streaming-00.txt has been successfully submitted by Andrew Gray and posted to the IETF repository. Name: draft-gray-sampled-streaming Revision: 00 Title: Sampled Traffic Streaming Document date: 2019-08-05 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-gray-sampled-streaming-00.txt Status: https://datatracker.ietf.org/doc/draft-gray-sampled-streaming/ Htmlized: https://tools.ietf.org/html/draft-gray-sampled-streaming-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-gray-sampled-streaming Abstract: This document standardizes the means of requesting a sampled capture stream from a router, receiving details about the resulting data flow, and the structure of the data flow itself. This is specifically tailored to having various hardware ASICs be able to perform this operation as quickly as possible, by allowing communication of the specific bit formats of headers applied to the packet flow, in a way that enhances interoperability between sources and sinks. Historically, NetFlow and its ilk have been used for these use cases, however the growth in hardware forward speeds is far outpacing the growth in CPU speeds, and the CPU-heavy parts of NetFlow is resulting in a reduction of sampling rates that include all of the fields provided by NetFlow that require CPU lookups. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
