Export Generated BGP Configuration Code

[wenovus]

Move internal/pkg/config -> pkg/config/gobgp

Background: #2593

Previously I opened #2599 but I think this approach is likely the best since it preserves backwards-compatibility with minimal changes.

[wenovus]

@fujita ping on this as the preferred way to address #2593, do you have any concerns?

[fujita]

renaming config to gobgp is really confusing; lost the context. I think that we needs a better name; openconfig? model?

[wenovus]

renaming config to gobgp is really confusing; lost the context. I think that we needs a better name; openconfig? model?

Thanks, here is a list of options I've seen/thought of:

• I think openconfig might not appropriate since GoBGP has augmented the original models, essentially creating its own "vendor models".
• In keeping with "I don't think using bgp prefix for gobgp packages is a good idea. Just verbose.", then model sounds better to me. (preferred)
• I'd like to propose gobgpoc, where oc is a common abbreviation for "openconfig", and gobgp qualifies it as being a vendor-augmented form of OpenConfig rather than the standard, pure OpenConfig from https://github.com/openconfig/public
• There is another option described here: Make generated BGP configuration code public #2599 (comment)

  pkg/internal/config -> pkg/config
  pkg/config -> pkg/configop, or pkg/gobgp
  

  the downside is the renaming of an already-exported package which may necessitate a major version bump. This is because it's possible for a user to be using config.ReadConfigFile and config.InitialConfig to write their own gobgpd.

[fujita]

OpenConfig is supposed to be used to build vendor models?
What vendor uses pure OpenConfig model?

[wenovus]

OpenConfig is supposed to be used to build vendor models? What vendor uses pure OpenConfig model?

Yes OpenConfig is the model used to access vendor device features. Ideally no vendor deviations/augments are required but they do happen. For example in openconfig/featureprofiles, tests are written using the "pure" OpenConfig models, but there are if conditions in the tests that check deviations from the pure model that different vendors may have. The pure model itself is also constantly changing to meet new requirements or for other improvements, which is why it's now starting to be versioned.

Therefore as a user of GoBGP, I see pkg/config/? as a non-pure OpenConfig catered to GoBGP since the YANG file has been augmented with new features in multiple places, whereas featureprofiles's API is pure OpenConfig since its YANG is non-altered: https://github.com/openconfig/ondatra/blob/main/gnmi/generate.sh, hence why it's named oc.

[fujita]

Using gobgp twice in package path is confusing, so model or oc works for me.

[wenovus]

Using gobgp twice in package path is confusing, so model or oc works for me.

Actually now I prefer oc a bit more because the model is largely based off of OpenConfig and therefore is a pretty representative name. The fact that it exists in GoBGP should warn users that it may deviate from the pure OpenConfig models.

PTAL, thanks.

[fujita]

pushed, thanks!