add bgp comm regex-match

[dplore]

Change Scope

• Add OC type for posix extended regular expressions.
• Change the union type for BGP community sets to use posix extended regular expression.
• Clarify how the regex is used when matching communities.

Rather than using various implementation specific regex implementations

1. A posix regex format is proposed to be used for BGP community sets.
2. An algorithm for BGP communities to be matched is proposed to make it clear how the regex-match leaf will behave.

The result is a vendor neutral method for writing regex for BGP communities which can be tested. Testing is possible because the regex implementation is standard and implemented in many open source development and testing tools versus the proprietary regex that are present today.

This is an incremental step towards an end state for bgp community set modeling described in #883

Tree Representation

Since this is only a type and description change, there is no change to the OC tree. Affected paths are:

• /routing-policy/defined-sets/bgp-defined-sets/community-sets/community-set/config/community-member
• /routing-policy/defined-sets/bgp-defined-sets/ext-community-sets/ext-community-set/config/ext-community-member

Platform Implementations

Regex based pattern matching for community is widely implemented but most use a proprietary format for the regex. References are included for comparison of BGP community regex matching behavior.

• Cisco IOS XR community matching explicitly supports regex evaluation for one community at a time.
• JunOS community matching using regex

[OpenConfigBot]

Major YANG version changes in commit 38d0ccd:
openconfig-bgp-errors.yang: 5.6.0 -> 6.0.0
openconfig-bgp-policy.yang: 6.4.0 -> 7.0.0
openconfig-bgp-types.yang: 5.6.0 -> 6.0.0
openconfig-types.yang: 0.6.0 -> 1.0.0

[wenovus]

@dplore based on the fact it's not reproducible locally and that random threads are being killed, I'm guessing it's because since all the models were running in parallel, the build machine went OOM and decided to kill one of the pyangbind threads.

Making ygnmi run after pyangbind (empirically these two were the ones conflicting with one another) seems to resolve this issue. But if this happens let me know and I'll make the processes more serial.

In the future I think it makes sense to move to one of the high memory private worker pool nodes. It doubles the build cost but will give us 4x more memory.

---

Please review openconfig/models-ci#98 and then I will fix up cloudbuild.yaml.

[wenovus]

@dplore fixed up now. For any other affected PRs, they will need to merge from the main branch to see the new results.

[dplore]

@earies @rgwilton @hellt I would appreciate your feedback as well.

[dplore]

Last call, this will merge on March 11th.

[jhaas-pfrc]

The fundamental request here is "use full ieee extended regex".
IETF chose to go with a restricted subset of this to cover what vendors generally ship. For the most part, the identified subsets are unsupported for a few reasons:

1. CLI syntaxes don't permit some of the patterns - i.e. it introduces ambiguity in a cli context or potentially introduces restricted or unsafe characters like backslash.
2. backrefs can break match caching, even when they're extremely helpful. This means a potentially heavy hit to routing pipelines.

NOTE: regular expressions are generally the worst performing policy element in policy engines across all vendors. Vendors spend a lot of energy avoiding such performance hits or letting customers shoot themselves in the foot too much.

My recommendation would be for OC to support some form of the IETF restrictions for maximal compatibility across vendors.

From https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model:

typedef bgp-community-regexp-type {
type string;
description
"Type definition for communities specified as regular
expression patterns.

   A compliant implementation of this type MUST accept a POSIX.2
   Extended Regular Expression excluding the following features:
   - character class expressions (Section 9.3.5)
   - collating symbols (Section 9.3.5)
   - equivalence classes (Section 9.3.5)
   - back-reference expressions (Section 9.3.6)

   Implementations MAY accept additional forms of regular
   expressions as long as the minimally compliant form documented
   above is accepted.";
reference
  "IEEE Std 1003.1-2017: The Open Group Base Specifications Issue
   7, 2018 edition.";

}

[dplore]

The fundamental request here is "use full ieee extended regex". IETF chose to go with a restricted subset of this to cover what vendors generally ship. For the most part, the identified subsets are unsupported for a few reasons:

1. CLI syntaxes don't permit some of the patterns - i.e. it introduces ambiguity in a cli context or potentially introduces restricted or unsafe characters like backslash.
2. backrefs can break match caching, even when they're extremely helpful. This means a potentially heavy hit to routing pipelines.

Thanks for this feedback, it's very helpful. I've added a constraint and reference to the IETF draft.

[dplore]

@robshakir can you re-review/approve? I fixed the community-member union type to point to the intended bgp-community-regex type which introduced the constaints on top of the posix extended regex type. (The earlier approved commit was still referencing the 'plain' posix extended regex type)