Re: [Idr] Compatibility of draft-ietf-idr-bgp-model-16 with BIRD

[Maria Matejka <[e-mail]>]

Hello Jeffrey,

thank you for your detailed answer!

On 6/27/23 18:40, Jeffrey Haas wrote:
>> 1. We don't index BGP neighbors by IP addresses, we name them by
>>     user-defined strings. It's possible (at least in testing setups)
>>     that there are multiple (possibly hundreds) BGP neighbors on the
>>     same IP address just with a different port, configured on the other
>>     side as passive. Does it make sense to somehow "extend" this in our
>>     BGP-YANG extension, or should we try to "upstream" this to the draft?
> This is actually a critical detail to resolve as early as possible since
> keys inside of lists aren't subject to revision according to YANG rules.
> It's a very non-backward-compatible change.
>
> There's also a bit of history for controversy on such keying.  The RFC 4273
> MIB keys only on the remote peer address - and only for IPv4 since that's
> all that MIB was able to support.
>
> There was ancient work (one of my first IETF projects) to try to update the
> MIB for IPv6 and "fill in the gaps" for missing functionality.  This was
> covered by draft-ietf-idr-bgp4-mibv2.  It was also sadly my introduction to
> "IETF doesn't necessarily know what it wants".  So, the MIB wandered around
> competing requirements from the IETF ops community to try to make BGP
> configurable, and also properly cover the state BGP carries.
>
> One structural change early in that MIBv2 work prior to -09 was that
> neighbors were indexed by local and remote addresses rather than solely
> remote address.  This would at least permit more than one peering session
> between two routers when the same remote address was being used.  There was
> discussion, but no work done, to also permit the ports to be included as
> part of the key.
>
> The eventual consensus from the working group was "BGP runs on port 179,
> don't worry about modeling anything else".
>
> If BIRD has support for RFC 4273, it likely already has a flavor of the
> issue you're discussing already.
>
> Similarly, the OpenConfig YANG module for BGP also uses the remote address.
>
> I agree the type of test scenario you're describing can happen and can't be
> accommodated in the current model. It's unclear what an appropriate change
> might be to add the flexibility you're looking for without potentially
> causing other issues in the module where keys are expected to be shared for
> the neighbor entry.  We'd certainly discuss potential patches you may have.
> YANG has much more flexibility than SMIv2 did for MIBs and much of the
> reason we left MIBs behind was that lack of flexibility.

Currently, "grouping bgp-neighbor-list" requires indexing by peer 
"ip-address". This is wrong, because I can have two legitimate peers 
running on the same LLv6 on different interfaces. This is also a bug in 
the "grouping bgp-neighbor-config". The minimal fix of this is to switch 
to "ip-address-zoned" or better maybe unionize it.

Yet this is not enough as I can have two legitimate BGP connections with 
the same peer and two different local addresses, thus we need at least a 
combination of the local and peer address. (This alleviates the need for 
zoned IP, paradoxically.)

For BIRD, this is still not enough as we support having multiple 
pre-defined configuration blocks for the same peer and switching them 
atomically like "birdc enable foo && birdc disable bar".

This way, as the IP addresses are strings anyway, I'd suggest expanding 
the key to any string. Every implementation relying on these keys being 
IP addresses must validate them as these anyway and we can use our 
string identifiers freely. This is IMHO a non-breaking change and I'll 
send a pull request about this soon.

BTW sending the IP addresses as strings (no other representation is 
defined in "openconfig-inet-types") is also weird when it could be just 
two uint64 for IPv6 and one uint32 for IPv4. But it looks mostly like 
the YANG being defined primarily atop JSON and XML with CBOR coming 
maybe little bit to late? We're definitely not going to support anything 
else than CBOR internally. We wanna get rid of number-to-text formatting 
as much as possible.

We can also have multiple neighbor indexes, like 
"bgp-neighbor-list-by-peer-address" of lists of neighbors having the 
given peer address, and "bgp-neighbor-list" of neighbors directly, 
indexed by unique identifiers defined by the implementation.

>> 2. Our policies are quite a free-form short scripts which can't be
>>     straightforwardly represented in this YANG, and I'm very afraid that
>>     we just fail to represent our more intricate filters in anything
>>     compatible with this YANG at all.
> The current bgp-specific policy in this module is intentionally skeletal and
> doesn't cover all possible current policy engines.  YANG does permit
> extending the policy using augmentation, but there's some expectation that
> the skeleton used by the IETF routing policy module is reasonable for your
> implementation.  If that skeleton is completely inappropriate, there's
> probably a much larger conversation covering that point.

Your last sentence describes it best. For BIRD, the skeleton covers a 
negligible part of our policy options and in some cases (e.g. 
community-set-name) unsupported. Also the bgp-community-regexp-type, 
marked as TODO, will not be supported even after being defined. We don't 
regexp at all.

Also our policies include route origin validation and can be branched 
based on them … but ROV is apparently another YANG model – 
draft-liu-sidrops-rtr-yang – which seems not much connected to BGP policies.

I simply can't figure out how to represent our filter looking like this 
(which is one of the simpler variants of what is really being run in IXPs):

import filter {

   case roa_check(db) {

     ROA_VALID: do_something_for_valid();

     ROA_INVALID: do_something_completely_different();

     ROA_UNKNOWN: case roa_check(another_table) {  ... }

   }

   ...

};

Representing our policies would, from my point of view (which may be 
wrong), basically mean to define a completely different YANG model for 
policies, using probably only the types.

This way, yes, I'd like to open a much larger conversation about this.

>
>> 3. There are several occurences of this regex, attempting to represent
>>     32-bit integers (e.g. at page 117):
>>     '(4[0-2][0-9][0-4][0-9][0-6][0-7][0-2][0-9][0-6]|'
>>     + '[1-3][0-9]{9}|[1-9]([0-9]{1,7})?[0-9]|[0-9])'
>>     which doesn't e.g. match 4199999999; also another regex on page 119
>>     (bgp-ext-community-type) mismatches 16-bit integers, like 64999;
>>     curiously, another regex on page 125 (bgp-set-med-type) does the
>>     32-bit integers right.
> Feel free to open an issue on the github for the module and we'll address
> it.  If you've not opened one after I've returned from holiday, I'll do so.
>
> Using POSIX-style regex to cover range restrictions in YANG is probably one
> of my less favorite quirks of the language because it makes it easy to have
> bugs like this.

Maybe better question is, why to have the textual representation in the 
first place. I thought that YANG should be a description for machine 
interface primarily … but maybe I am missing something important.

>> 4. Also the large community representation seems to not allow any
>>     binary format (page 117) which is strange in my eyes.
> You likely have noticed that extended communities have a lot of work around
> them to try to provide a level of flexibility.  However, they were
> challenging to get "right" in the current flavor and even now will make a
> number of people managing the YANG language unhappy about their maintenance.
>
> What would you propose for the "binary" formats for large communities?
Well, like a grouping foo { leaf asn { type uint32; } leaf data1 { type 
uint32; } leaf data2 { type uint 32; } } or even ultimately a type 
binary { length 12; } as with bgp-ext-community-recv-type?
>> I explicitly state that this is not the full list of my concerns,
>> I'm trying to get at least some grip on this so if there was anybody
>> to point me the right way to approach this, I'd be really happy.
> IDR list discussion is certainly one way to do it.  The github is another
> using issues, although anything besides simpler maintainance will eventually
> revert to IDR list discussion.
OK, I'll stick with this list, trying to pry away layers of complexity 
and find my way into understanding this. Thank you for your patience. 
It's a huge block of data to parse and thoroughly think through.
> And should you, or others working on the project, be coming to the upcoming
> IETF, I'm sure the module authors can spend some time on open discussion on
> the module.

I'm coming to IETF 118 Prague surely but not to IETF 117 SF as I haven't 
planned for it and now it's too late. Anyway I suppose that with all the 
work to do, postponing this to IETF-118 makes not much difference.

Thank you for your answers, see you later!
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.