Re: [OPSAWG] IETF 106 Discussion about draft-gray-sampled-streaming - room moved

["Gray, Andrew A" <[e-mail]>]

Thanks to those who came to the side session and have otherwise provided feedback.  I took notes on the feedback from that meeting combined with the main presentation and other notes:

- Should incorporate the "why not other stuff" into the draft
- Compare/contrast versus RFC 5476 
- How are the resulting entries in a forwarding ASIC's CAM ordered versus real ACL entries populated by another entity?  The replicator already has to do ACL merging between ACLs, QOS policies, and other sampling - is this actually a problem? 
- How are multiple sampling sessions impacting each other (i.e. if a more specific sampler is installed at 1:10 to destination A, and a common sampler is installed at 1:1000 to destination B, does the traffic from the first also appear in the second?).  Generally consensus is that it shouldn't, and depending on platform can't without a recirculation penalty.  Should this be handled in the Proposals somehow?
- Possibly reference IPFIX fields as defined in https://www.iana.org/assignments/ipfix/ipfix.xhtml (possibly as the resulting mapping table on export?)
- Need to do more to explain how this compares and fits into an IPFIX deployment.
- Clarify the current performance penalty is only forwarding capacity
- What about LAGs?  Service/customer/VLAN interfaces?  LAGs are highly problematic between the ports may be sprayed across different ASICs with different capabilities but if a Replicator wants/can offer the option at a reduced set, it should be allowed.  Clients probably should expect to have to grab the member ports individually, however.
- Research more on the filter definition - feedback was this isn't standardized because it's hard to standardize even one item (ACLs for example) across different platforms.  In addition, sampled streaming has unique filtering requirements (filter against what action is going to be taken).  May be best off just sticking with local definition, but still should research other implementations and make sure things like field names/sizes/definitions match up where we can.
- Proposals can offer different filter sets than requested as is, but this is only mentioned in the YANG model (along with some other tidbits) - need to pull into the body of the draft
- Freeform performance penalty (points?) - finger in the wind numbers (make sure to emphasize that it is an estimate) - include things like other resources used (CAM entries, memory, etc?).  Number would only be relative to the device itself.
- Informational or Standards track?

If I missed something, please let me know, and thanks to all who have provided feedback to date.  I'm planning on working through these issues and releasing a -03 within the next couple weeks.
 

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.