<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Or do the sensible thing and just drop the announcement and log the problem. <br></blockquote><div><br></div><div>Which is exactly what an RFC7606 compliant device will do for an unknown path attribute. </div><div><br></div><div><a href="https://www.rfc-editor.org/rfc/rfc7606#page-5">https://www.rfc-editor.org/rfc/rfc7606#page-5</a></div><div><br></div><div><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)">   o  Treat-as-withdraw: In this approach, the UPDATE message containing
      the path attribute in question MUST be treated as though all
      contained routes had been withdrawn just as if they had been
      listed in the WITHDRAWN ROUTES field (or in the MP_UNREACH_NLRI
      attribute if appropriate) of the UPDATE message, thus causing them
      to be removed from the Adj-RIB-In according to the procedures of
      [<a href="https://www.rfc-editor.org/rfc/rfc4271" title=""A Border Gateway Protocol 4 (BGP-4)"">RFC4271</a>].</pre></div><div><br></div><br>   d.  If any of the well-known mandatory attributes are not present in<br>       an UPDATE message, then "treat-as-withdraw" MUST be used.  (Note<br>       that [RFC4760] reclassifies NEXT_HOP as what is effectively<br>       discretionary.)<br><br>   e.  "Treat-as-withdraw" MUST be used for the cases that specify a<br>       session reset and involve any of the attributes ORIGIN, AS_PATH,<br><div>       NEXT_HOP, MULTI_EXIT_DISC, or LOCAL_PREF.</div><div><br></div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 30, 2023 at 10:01 AM Eugeniu Patrascu <<a href="mailto:eugen@imacandi.net">eugen@imacandi.net</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"><div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 30, 2023 at 4:04 PM William Herrin <<a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</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 Wed, Aug 30, 2023 at 4:50 AM Mike Lyon <<a href="mailto:mike.lyon@gmail.com" target="_blank">mike.lyon@gmail.com</a>> wrote:<br>
> Ran across this article today and haven't seen posts about it so i<br>
> figured I would share:<br>
><br>
> <a href="https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling" rel="noreferrer" target="_blank">https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling</a><br>
<br>
Can you imagine, as the origin of a route, troubleshooting a<br>
connectivity issue in which Internet BGP routers far from your control<br>
have trouble with attributes attached by their peers and then "did<br>
their best" with your route instead of dropping the session and<br>
essentially demanding intervention by the network operator?<br>
<br>
Dumping the session may seem extreme, but there's a good reason for it.</blockquote><div><br></div><div>Or do the sensible thing and just drop the announcement and log the problem. </div><div>This might be a problem in a DFZ environment, but albeit a small one.</div><div>Or, drop the invalid attribute and treat the announcement as a regular one.</div></div></div>
</blockquote></div>