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.
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to