gRIBI aft v3.5.0

[dplore]

This pull request updates the gRIBI AFT (Abstract Forwarding Table) protobuf and Go module dependencies to extend the AFT schema for backup activation support.

Protocol Buffer Schema Extensions:

• Introduced BackupActivation message to the Afts message in gribi_aft.proto, supporting backup activation tracking per next-hop group.

Generated Go Code:

• Regenerated enums.pb.go with a newer version of protoc-gen-go,

Dependency Updates:

• Updated the Go module to require Go 1.26 and upgraded dependencies (ygot, grpc, protobuf, and added new indirect dependencies)

[nandanarista]

hi darren, thank you for taking care of this!

since backupActivation is a new top level AFT, i think we also need to update gribi.proto with the new enums and pointers in the request and get response

ie,

• entry union (ModifyRequest)

  gribi/v1/proto/service/gribi.proto

  Line 191 in 69e0fb2

  oneof entry {

• AFTType enum

  gribi/v1/proto/service/gribi.proto

  Line 428 in 69e0fb2

  enum AFTType {

• AFTEntry (part of GetResponse)

  gribi/v1/proto/service/gribi.proto

  Line 467 in 69e0fb2

  message AFTEntry {

if you were planning to add these in a separate PR, that is fine too
thanks!

[dplore]

backupActivation

Thanks for pointing this out, updated gribi.proto with the backup_activate fields.

[nandanarista]

hi darren, looks great; please regen the gobindings and we should be good to go

[aayueshbarui]

Thanks!

[nandanarista]

lgtm, thank you again!

[yiminshen49]

Questions about BackupActivation -

[1] What is the expected AFTResult of Modify response if the target NHG does not have a backup NHG ? Should the entry to accepted with FIB_PROGRAMMED/RIB_PROGRAMMED (per ACK mode) or rejected with FIB_FAILED ?

[2] Same question as above for the case where the target NHG has a backup NHG but all the backup NHs are down or nonviable ?

[3] Assuming backup NHG is in activated state. What is the expected behavor when all the backup nexthops go down or become nonviable? Should traffic be kept on the backup nexthops as expected, or switched back to viable primary nexthop(s) ?

[dplore]

Deviate unsupported decap-mpls-label-stacks and encap-mpls-label-stacks for this release. These leaves may be added when there is a specific use for them in the future.