Community lists for extended BGP communities

[ipspace]

The routing.community object currently supports only standard BGP communities. It would be nice to have community lists that would match extended or large communities.

Unfortunately, that probably means we'll have to restructure the routing.community data format to add type (or something) top-level attribute that specifies which type of community list we're describing.

[ipspace]

@jbemmel @ssasso @DanPartelly @Muddyblack @steffann @ddutt @nmodena -- any preference on how we'd structure the extended/large community lists?

I see three options:

Per-entry community type

routing.community:
  std_1:
  - action: permit
    list: [ 65000:1 ]
  - action: deny
    regexp: _65000:1.._
  ext_1:
  - action: permit
    list: [ rt:65000:1 ]
    type: extended
  - action: deny
    list: [ rt:65000:.* ]
    type: extended

In this case, we could potentially split a single community list with different type values into multiple device ACLs (potentially confusing). Alternatively, we would report an error if type does not match across entries.

Specify community list type

routing.community:
  std_1:          # Simplified standard community list
  - action: permit
    list: [ 65000:1 ]
  ext_1:          # Extended community list
    type: extended
    value:
    - action: permit
      list: [ rt:65000:1 ]

Advantage: clean data model

Drawback: more verbose for large/extended community lists

Guesswork

If the entries are "a:b", then it's a standard community list, if they're "a:b:c" then it's a large community list, if they're "rt:..." or "soo:..." then it's an extended community list.

Drawback: doesn't work well when the user starts using regular expressons :(

[jbemmel]

I would prefer the per-entry community type, and by default I would like to see Netlab "guess" the correct type ( == more basic type that can support the requested entry ). If it cannot detect automatically (e.g. in case of regular expressions), ask the user to explicitly specify what is intended (and error if it's not matching)

Then, add a global parameter to always require explicit community types (default: False), for people who are trying to teach networking and want their students to think about this in more detail

[steffann]

I like the “Specify community list type” style. Guessing might be a useful fallback, but I’m generally more the in “explicit is better than implicit” camp :)

[jbemmel]

I like the “Specify community list type” style. Guessing might be a useful fallback, but I’m generally more the in “explicit is better than implicit” camp :)

We could choose to set the default to always require explicit community typing. The problem with #2 is that it doesn't allow for guessing

[ipspace]

We could choose to set the default to always require explicit community typing. The problem with #2 is that it doesn't allow for guessing

On a second thought (and lacking any other feedback so far), maybe it's a good idea to keep the code simple and bugs at bay.

Anyway, we need the type/value format as the final format, so I'm working on transforming the clist data into that format earlier in the transformation process so it can be used as a canonical format in lab topologies. Whether the type will be assumed to be standard or guessed is still for further study ;)

[ipspace]

Large communities were implemented in #2853, #2856 and friends