bfd - need more control on targets

[robric]

We can't specify the target destination for BFD sessions. this is problematic if multiple destination can be reached via BFD. Related question - how much should we link BFD with routing protocols (because that's ultimately where these are consumed)

[boucadair]

I guess you are referring to the ac-ntw model.

I suggest the following change:

OLD:

       |  +--rw bfd
       |     +--rw bfd-profile-ref?            leafref
       |     +--rw network-ref?
       |     |       -> /nw:networks/network/network-id
       |     +--rw session-type?               identityref
       |     +--rw desired-min-tx-interval?    uint32
       |     +--rw required-min-rx-interval?   uint32
       |     +--rw local-multiplier?           uint8
       |     +--rw holdtime?                   uint32
       |     +--rw authentication!
       |     |  +--rw key-chain?    key-chain:key-chain-ref
       |     |  +--rw meticulous?   boolean
       |     +--rw status
       |        +--rw admin-status
       |        |  +--rw status?        identityref
       |        |  +--ro last-change?   yang:date-and-time
       |        +--ro oper-status
       |           +--ro status?        identityref
       |           +--ro last-change?   yang:date-and-time

NEW:

|  +--rw bfd
          +--rw session* [dest-addr]
          |     +--rw dest-addr                    inet:ip-address
          |     +--rw source-address?          union
          |     +--rw bfd-profile-ref?            leafref
          |     +--rw network-ref?
          |     |       -> /nw:networks/network/network-id
          |     +--rw session-type?               identityref
          |     +--rw desired-min-tx-interval?    uint32
          |     +--rw required-min-rx-interval?   uint32
          |     +--rw local-multiplier?           uint8
          |     +--rw holdtime?                   uint32
          |     +--rw authentication!
          |     |  +--rw key-chain?    key-chain:key-chain-ref
          |     |  +--rw meticulous?   boolean
          |     +--rw status
          |        +--rw admin-status
          |        |  +--rw status?        identityref
          |        |  +--ro last-change?   yang:date-and-time
          |        +--ro oper-status
          |           +--ro status?        identityref
          |           +--ro last-change?   yang:date-and-time

[boucadair]

See #185

[robric]

In general BFD is hooked on routing protocols. Maybe a simple hook is enough ? like

• bgp

  neighbor

   bfd-profile-ref

• static routing next-hop XXX bfd-profile

R

[boucadair]

In general BFD is hooked on routing protocols. Maybe a simple hook is enough ?

Added the profile under BGP nighbor:

   |     |     +--rw bfd {vpn-common:bfd}?
   |     |     |  +--rw bfd-profile-ref?   leafref
   |     |     |  +--rw network-ref?
   |     |     |          -> /nw:networks/network/network-id

Please see the update PR. I maintained both changes.

[robric]

I had a closer look – how can we hook something on svc model ? No urgency, I will build a first iteration of my use case without BFD anyway, but that’s a nice to have to demonstrate how powerful the model is. R

[boucadair]

For the service model, I think that "bfd/profile" we do already have is sufficient. When it comes to the actual configuration, an implementation may go for a "centralized" bfd configuration or under a routing proto, which we now better support with the new changes in PR #185.

[robric]

I need to specify the list of target Ips. Indeed, since I am using a range for IP addresses of apps in computes, I don’t know which IP must be tracked by BFD.