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

[Jeffrey Haas <[e-mail]>]

Maria,

Apologies for response latency.  I'm taking some well-needed vacation and
I'm mostly out of touch until start of next week.  

However, I have a bit of connectivity today and wanted to at least partially
advance this thread.

On Wed, Jun 21, 2023 at 08:11:12PM +0200, Maria Matejka wrote:
> We are finally trying to adopt the draft-ietf-idr-bgp-model-16 in
> BIRD and we are struggling a lot with the structures proposed. I
> haven't yet fully parsed the draft, so I'm now just writing several
> concerns which I see with my current knowledge.

Thanks for the work.  Implementation is most likely to shake loose the
interesting issues.  

> 
> 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.


> 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.

> 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.

> 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?

> 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.

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.

-- Jeff