On Mon, Sep 16, 2019 at 09:54:36PM +0200, Iljitsch van Beijnum wrote: > On 16 Sep 2019, at 20:37, Job Snijders <[email protected]> wrote: > > > Limiting the AS_PATH length - from an IETF RFC publication process in > > context of providing operational guidance, probably shouldn’t be “limit the > > path length to avoid vendor bugs”. > > > Instead, the guidance perhaps should be “please report and fix bugs”, > > right? :-) > > In theory, yes. In practice, how does that work? Suppose I prepend 250 > times, and a few hops away, routers start to explode because they hit > 255 or 256 ASes in the path? How do these people debug the issue? Once > they know the problem, how do they install a temporary fix as they wait > for a real fix? > > Also, it's unlikely that any given bug will ever be completely > eradicated from the internet even if fixed software is available. The > real time global nature of BGP routing makes all of this much more > complex.
As one person writing BGP routing software I need to say that these issues are on us to fix and people should complain loudly about them. Writing a test with e.g. exabgp to exactly check this condition is not hard and can be added to any regress test. So having such a bug in production software is not acceptable. Also not updating your infrastructure systems is not acceptable either especially if you are providing transit to other customers that pay you. > And what if I make it 675 ASes instead and watch sparks fly as a few > hops away routers hit the 4096-byte BGP message size? > > Or I make it 700 ASes with only a 16-bit AS path or a truncated 32-bit > AS path, so the first 32-bit router that tries to create a 700-hop > 32-bit AS path exceeds 4096 bytes? You are applying a band-aid to a broken bone. There is many more ways you can push an UPDATE to over 4096 bytes. Using AS path alone is probably the least successful. There are many more transitive attributes that you can use to bloat an update. So whatever limit you come up with will not protect you from tripping over the message size limit. It would be great if there is a standards document properly describing what to do in such a case because this is one of the underspecified corner cases in the current spec. > Now all of these problems can easily be avoided by a 120 or so AS limit. > Currently, the longest path that I see at Routeviews is 45, with 40 > prepends. (That same network also advertises about a /13 worth of space > as 2200 individual /24s for good measure.) 120 won't be hitting any > overflow bugs, but it's still rather excessive at three times the > longest non-prepended path. Also, 40 prepends is not going to give you > anything that 39 prepends, or 30 or 20, for that matter, won't > accomplish. > > I've seen max path length limits of 40 or even as low as 20 mentioned. > > But before we decide _where_ to draw the line, we first have to decide > if we think this particular line should be drawn at all. It looks to me > like AS path length filtering is sufficiently common that trying to come > up with a coordinated limit as a best practice would be worthwhile. > > (BTW, as far as I'm concerned we deprecate the use of AS_SETs and > multiple AS_PATHs in order to remove some unnecessary complexity from > BGP.) It would be great if all the 2-byte AS complexity could be slowly removed. Allow systems to no longer accept sessions without the 4-byte AS capability and remove all the code to generate and merge AS4_PATH and friends. -- :wq Claudio _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
