SubscribeResponse.GetUpdate().Updates length varies in large telemetry updates

[pedroaston]

Context

I saw this behavior when testing dial-in telemetry with the proto encoding on Cisco IOS-XR routers.
The yang-path used was: Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/afs/af/networks/network
(added some keys to only receive the 0.0.0.0/0 route)
I developed a collector that uses this repo gNMI interface (v0.8.0).

Problem

When i start processing the update from the SubscribeResponse in the case of the proto encoding I iterate on the slice returned by SubscribeResponse.GetUpdate().Updates. The problem is that this slice's length is 559 and the number of updates in this subscribeResponse was supposed to be 1432. This razes the question if there is some limitation with this function? The strangest part is that when i fmt.Println the SubscribeResponse it prints the 1432 updates.

I tested with smaller SubscribeResponses (~40 updates) and the number of updates were the same in the SubscribeResponse.GetUpdate().Updates and in the printed SubscribeResponse. I don't know if you can help me understand this result, and see if there is any limit in the number of updates. From reading the specification i did not catch any reference to any limits.

I will place here the print of the SubscribeResponse in a text file.
cisco_bgp_network_yang.txt

Additional Context

• Cisco IOS-XR does not allow more fine-graned updates. This is the smallest sensor possible for me to receive a bgp feed. Some of the relevant data per network are the communities, as-path, path attributes (LP, MED, ...), rpki validity, next-hop, ...
• I have been using json_ietf encoding, but for bigger updates because i thought that proto encoding could allow me faster parsing of large sensor were only <5% of the data is of interest, and to save time in value-type checking. Using a single thread it takes me 30 minutes to process a full routing table bgp feed (>800k routes) when using json_ietf encoding.

Thanks in advance 😃

[robshakir]

hi!

if you're just calling &gpb.SubscribeResponse{}.GetUpdates().Updates then this is code that is in the generated .pb.go file, and should not have any constraint on the length that I am aware of. gRPC by default has a 4MB maximum message size, and you may need to look at grpc.MaxCallRecvMsgSize(), grpc.MaxCallSendMsgSize() in your client options to update this.

r.

[pedroaston]

Hey @robshakir,

the SubscriberResponse hitting grpc's msg size limit is not the issue. When running protobuf's Size(SubscriberRequest) the message size is 48708 bytes. The main question still remains: Why when I use SubscribeResponse.String() it shows all 1432 updates and when I use &gpb.SubscribeResponse{}.GetUpdates().Updates it only returns 559. With smaller SubscribeRequests the numbers are the same.

If there was an error in the packet format it would not use .String() correctly right? One of the attributes that isn't shown is as-path, but I can find it in the .String() returned. At first sight there seems no error in the format from the .String() result.

Thanks for the feedback