BFD model structure - profiles vs. interfaces

[exa-arrcus]

Given the current openconfig-bfd model excerpt

module: openconfig-bfd
  +--rw bfd
     +--rw interfaces
        +--rw interface* [id]
           +--rw id                    -> ../config/id
           +--rw config
           |  +--rw id?                            string
           |  +--rw enabled?                       boolean
           |  +--rw local-address?                 oc-inet:ip-address
           |  +--rw desired-minimum-tx-interval?   uint32
           |  +--rw required-minimum-receive?      uint32
           |  +--rw detection-multiplier?          uint8
           |  +--rw enable-per-member-link?        boolean
           +--ro state
           |  +--ro id?                            string
           |  +--ro enabled?                       boolean
           |  +--ro local-address?                 oc-inet:ip-address
           |  +--ro desired-minimum-tx-interval?   uint32
           |  +--ro required-minimum-receive?      uint32
           |  +--ro detection-multiplier?          uint8
           |  +--ro enable-per-member-link?        boolean
           +--rw interface-ref
           |  +--rw config
           |  |  +--rw interface?      -> /oc-if:interfaces/interface/name
           |  |  +--rw subinterface?   -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/subinterface/index
           |  +--ro state
           |     +--ro interface?      -> /oc-if:interfaces/interface/name
           |     +--ro subinterface?   -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/subinterface/index

The structure indicates a container with a list (common design pattern) named interface however the list-key is an abstract reference string. Within this list is a 1:1 interface-ref mapping to an interface/subinterface.

With that said, this seems to indicate this is more of a "profile" than an "interface" as the list key id can have nothing to do with an actual interface on the system. I tend to disagree with the terminology used here and propose this should likely rather be /bfd/profiles/profile. In either case, a profile and interface pair need to be mapped 1:1 in the current model design.

There are cases where per interface profiles may not be supported but rather a system/global level profile. If the container/list above are renamed to profile as such, then there is the potential this can be reused as such if a profile name (or introduction of a type) has special meaning (e.g. GLOBAL) - the list key could be a union between special meaning enum + user-supplied profile string

[exa-arrcus]

The above was raised some time back - has anyone had a chance to comment/review the above @aashaikh @robshakir ? Thx

[s19nal]

Hi Ebben - I'm looking at this. but very slowly, sorry! am trying to find more time but not easy currently. regards Simon

On Tue, May 12, 2020 at 5:10 PM Ebben Aries notifications@github.com wrote:

The above was raised some time back - has anyone had a chance to comment/review the above @aashaikh https://github.com/aashaikh @robshakir https://github.com/robshakir ? Thx

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openconfig/public/issues/319#issuecomment-627441593, or unsubscribe https://github.com/notifications/unsubscribe-auth/AETPOYAL2DSCLAIGSBFLPETRRFYHRANCNFSM4KJYBMIA .

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.