Inband Flow Analyzer feature specification. #427
Conversation
|
|
|
|
||
| ## 2.2 Functional Description | ||
|
|
||
| The IFA feature allows user to configure a device as ingress, intermediate and egress nodes through PACKET\_ACTION field in ACL rule. PACKET\_ACTION field values INT\_INSERT, INT\_UPDATE and INT\_DELETE specifies ingress, intermediate and egress devices respectively. Each device type performs its own unique operations as mentioned below. |
There was a problem hiding this comment.
Can the spec expose the ASIC capabilities to the user ?
There was a problem hiding this comment.
Hi,
There is a PR submitted by Vissu with regard to exposing ASIC's capabilities, opencomputeproject/SAI#989. This issue can get addressed as a part of the same PR.
|
|
||
| At egress node, IFA probe packets are identified and IFA meta-data is inserted. Egress node terminates IFA session and summarizes the telemetry data for the entire path, encapsulates the telemetry data as payload and sends it to collector. | ||
|
|
||
| At all other non-IFA nodes, IFA sampled packet is forwarded as a normal packet in the network. |
There was a problem hiding this comment.
How to handle single point failures with egress node? do you have suggestions to egress node configurations in the network topology?
|
|
||
| ## 3.6 CLI | ||
| ### 3.6.1 Data Models | ||
| NA |
There was a problem hiding this comment.
do you have a plan to define data models for the feature?
There was a problem hiding this comment.
Data models based on new management framework will be defined, once management feature is supported in SONiC.
| ## 3.5 SAI | ||
|
|
||
| The SAI TAM API spec defines all TAM APIs supported in SAI. Please refer to SAI-Proposal-TAM2.0-v2.0.docx in [https://github.com/opencomputeproject/SAI/tree/master/doc/TAM](https://github.com/opencomputeproject/SAI/tree/master/doc/TAM) for more details. | ||
|
|
There was a problem hiding this comment.
Please specify the SAI API sequence. The referred spec has multiple options for things like bind (source and object), marking the telemetry traffic etc. It would be easier to follow if the SONIC spec lists exactly what APIs and parameters it is using for this release.
| "IP_TYPE" : "ipv4any", | ||
| "SRC_IP" : "10.10.0.26/32", | ||
| "DST_IP" : "10.10.1.26/32", | ||
| "PACKET_ACTION" : "int_insert" |
There was a problem hiding this comment.
Why not use the command config ifa device-type ingress to configure a device as ingress?
| "IP_TYPE" : "ipv4any", | ||
| "SRC_IP" : "10.10.0.26/32", | ||
| "DST_IP" : "10.10.1.26/32", | ||
| "PACKET_ACTION" : "int_delete" |
There was a problem hiding this comment.
Why not use the command config ifa device-type egress to configure a device as egress?
|
|
||
| # 1 Feature Overview | ||
| The Inband Flow Analyzer (IFA) feature allows configuration of an IFA session that could provide Inband-telemetry over sampled live traffic to collectors. A network monitoring application can analyze the telemetry information provided by IFA feature and provide full visibility of a network by providing metrics such as latency, packet loss and full network path that packet travels. IFA feature in SONiC will be compliant to RFC [https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa](https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa). | ||
|
|
There was a problem hiding this comment.
Hi,
Is this feature similar to DTEL from Barefoot?
Thanks
| 4) 10.20.30.40 | ||
| 5) "port" | ||
| 6) 9070 | ||
|
|
There was a problem hiding this comment.
Is the communication to the collector from the switch is through the front panel routing interface or via management port?
This specification provides high level overview of Inband Flow Analyzer feature.