Add gNOI Packet Capture service

[Raj998]

• Added proto and generated go files for packet capture service.

References

• References to several implementations are in the gNOI PCAP proposal
• As this change is a new proto, the change is backwards compatible to gNOI

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

For more information, open the CLA check for this pull request.

[earies]

I'm curious - Do you have a specification or architectural document describing the full intention of these APIs (or planning to publish)?

Is this intended for pcap on network-elements and thus limited to punted/non-transit traffic?
Is this meant to correspond with user-space utilities such as tcpdump? (assume so since there is reference to an opaque string filter expression)
How come the limitation of TCP/UDP L4 protocols?
The loose relationship between filter_name and supported schemas on a target assumes some level of support on shipping implementations? Do you have any such references?
What are the characteristics for response stream (much like definitions in file.proto) as well as how the data field is to be encoded?
Generally, implementations that support some level of pcap, have the ability to write to stdout/filesystem which should likely be accounted for. Streaming captures remotely could very well exacerbate issues under certain conditions and thus believe that there should be surrounding specifications and guidelines outlined as to the full usage of this API

[Raj998]

Addressing your questions @earies -

I'm curious - Do you have a specification or architectural document describing the full intention of these APIs (or planning to publish)?
-> Yes, you can find the link to the public doc below -
https://docs.google.com/document/d/1bwvTzbmJAsc7YSfhCpY_mDzHwWfaC7DISD-Xw_0n7KI/edit

Is this intended for pcap on network-elements and thus limited to punted/non-transit traffic?
-> No, it would not be limited to punted traffic

How come the limitation of TCP/UDP L4 protocols?
-> Yes, we can add other protocols like DHCP, DNS, ARP, ICMP, RADIUS etc.

Generally, implementations that support some level of pcap, have the ability to write to stdout/filesystem which should likely be accounted for -
-> We had initially thought of it but later decided to remove it, to keep the functionality focused on the streaming response. Anyway we can handle this in a future PR.

[xavier-contreras]

@earies , does the document and previous answer help with some of your questions?

For the characteristics of the data field, I'm not sure what the expectation should be. Looking at a generic stream bytes API (with streaming response), I do not see a lot of details: https://github.com/googleapis/googleapis/blob/master/google/bytestream/bytestream.proto#L53

Unless otherwise documented, would it be reasonable for defaults to apply?
https://developers.google.com/protocol-buffers/docs/proto3#scalar

[xavier-contreras]

This looks good to me; It's a good baseline to start from and can be expanded/enhanced in a future PRs

[dplore]

@Raj998 you will need to sign the Google CLA before we can accept this contribution

[Raj998]

Some of the initial commits were done by different email address because of which CLA check was failing and accidentally I did a " git rebase -i --root " instead of "git rebase -i <earlier_commit_hash>" to change author for the earlier commits which lead to this mess. Extremely sorry for the inconvenience caused.

[xavier-contreras]

This looks good to me, we can build off of this.

[WFDU-HPE]

Aruba is ok with this

[xavier-contreras]

This service has been reviewed and approved by two vendors (Arista, Aruba) - and was a collaboration with a network operator (Google). This is ready for review and merge.

[mike-albano]

LGTM, nice work on the collaborative approach.

[dplore]

/gcbrun