<div dir="ltr">I will add a documentation patch in attachment.<br><br>I will also add a patch that removes BGP ROLE MAX from consideration, as was discussed before in a private conversation. This will make the previous patch with Roles more reliable and secure in case new roles suddenly appear in the future.<br><br>However, after creating a documentation patch and consulting with the main RFC author, I ran into trouble.<br><br>TL;DR: What are the best ways to include AFI/SAFI channel check during attribute creation?<br><br>RFC 9234 specifically clarifies that it can only be applied on IPv4/IPv6 unicast sessions. On all other sessions the OTC attribute should be decoded from and also transferred to such sessions without any change.<br><br>The problem is how to include AFI/SAFI checks in the code:<br>1) If we have information about a channel (as in <i>bgp_update_attrs</i>), we can simply run the following check<br><div style="text-align:left"><span style="font-size:x-small"><font face="monospace">proto/bgp/attrs.c</font></span></div><font size="1" face="monospace"><div style="text-align:left">if (bgp_channel_is_role_applicable(c)) { ... }</div><div style="text-align:left">proto/bpg/bgpd.h</div><div style="text-align:left">static inline int bgp_channel_is_role_applicable(struct bgp_channel *c)</div><div style="text-align:left">{ return (c->afi == BGP_AF_IPV4 || c->afi == BGP_AF_IPV6); }</div><div style="text-align:left"><br></div><div style="text-align:left">static inline int bgp_cc_is_role_applicable(struct bgp_channel_config *c)</div><div style="text-align:left">{ return (c->afi == BGP_AF_IPV4 || c->afi == BGP_AF_IPV6); }</div></font><div style="text-align:left">2) However, in <i>bgp_decode_attrs </i>the AFI/SAFI information is only available after NLRI decoding. There is also a side approach with using <i>bgp_find_update_afi,</i> a<i> </i>static function from proto/bgp/packets.c to extract AFI/SAFI from a packet payload. The question is - what is the best way to extract AFI/SAFI information: apply OTC rules after NLRI is decoded (but where?) or change and reuse static bgp_find_update_afi (if possible) to get AFI/SAFI information before processing the OTC attribute?</div><div style="text-align:left">3) But the biggest problem is with <i>bgp_preexport</i>. It uses bgp_proto, which doesn't use channel information when filtering routes with BGP specific rules. And I don't find a way to add this support to this filter. The question is - how to apply AFI/SAFI check for OTC attribute rules during bgp export and where is the best place to do so? Of course, if we want it to be like a predefined route-map.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 2, 2022 at 6:31 PM Ondrej Zajicek <<a href="mailto:santiago@crfreenet.org">santiago@crfreenet.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, May 31, 2022 at 02:38:07PM +0300, Eugene Bogomazov wrote:<br>
> Hello,<br>
> <br>
> RFC 9234 provides a new mechanism for route leak detection and prevention.<br>
> <br>
> In the attachment you can find a patch which introduces this functionality<br>
> for BIRD 2.0.9.<br>
<br>
Hello<br>
<br>
Thanks for the patch, i will check it soon. One issue i just noticed,<br>
could you also add patch for documentation (doc/bird.sgml), documenting<br>
these options?<br>
<br>
-- <br>
Elen sila lumenn' omentielvo<br>
<br>
Ondrej 'Santiago' Zajicek (email: <a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>)<br>
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, <a href="http://wwwkeys.pgp.net" rel="noreferrer" target="_blank">wwwkeys.pgp.net</a>)<br>
"To err is human -- to blame it on a computer is even more so."<br>
</blockquote></div>