North bound interface (CLI/REST clients) support for configuring FRR BGP

[venkatmahalingam]

1. Extend and provide unified configuration and management capability for FRR-BGP features used in SONiC.
2. Allow the user to configure & manage FRR-BGP using SONiC Management Framework with Open Config data models via REST, gNMI and also provides access via SONiC Management Framework CLI as well.

[msftclas]

All CLA requirements met.

[pavel-shirshov]

1. Please convert all pictures to .png. jpeg doesn't work good for diagrams

2. Suggest to split the proposal to two parts: north-bound to DB, DB to SONiC FRR

3. Suggest to use special utility to generate the database schema from YANG model automatically. Don't write the schema manually.
   .4. Suggest to rewrite bgpcfgd in go

4. Suggest to introduce validation loop: first northbound interface check syntax rules, then bgpcfgd uses frr to validate generated bgp configuration.

5. Suggest to return validation errors from bgpcfgd back to the requested. syslog message is not enough

6. What if some parameter is already configured and there is conflict of something being already in the database. What should we do? overwrite? remove old parameter and create new parameter?

7. What if some parameters are depends on the parameters which is changed by some rest request. How we can be sure we work with the parameters successfully?

[venkatmahalingam]

1. Please convert all pictures to .png. jpeg doesn't work good for diagrams
   Sure.
2. Suggest to split the proposal to two parts: north-bound to DB, DB to SONiC FRR
3. Suggest to use special utility to generate the database schema from YANG model automatically. Don't write the schema manually.
   .4. Suggest to rewrite bgpcfgd in go
4. Suggest to introduce validation loop: first northbound interface check syntax rules, then bgpcfgd uses frr to validate generated bgp configuration.
5. Suggest to return validation errors from bgpcfgd back to the requested. syslog message is not enough

Thanks for all your suggestions, will discuss internally and take up if required now.

6. What if some parameter is already configured and there is conflict of something being already in the database. What should we do? overwrite? remove old parameter and create new parameter?

If there are multiple config sources, it's hard to keep the configs in sync, for now, the short answer is, it is beyond our scope of the work.

7. What if some parameters are depends on the parameters which is changed by some rest request. How we can be sure we work with the parameters successfully?

We handle the dependencies in CVL layer (mgmt-framework), if there are any specific example, let us know, will try to see if that is already handled.

[venkatmahalingam]

@lguohan Please review the changes again, if everything looks good, merge the PR. Thanks.

[lguohan]

merge this as it is. the yang model discussion for this is still ongoing in the community.