Subject: [GROW] Limiting AS path length?

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 16 Sep 2019 10:21:08 +0200

Dear Global Routing Operators,

I attended a presentation by someone from a tier-1 network who talked about BGP filtering. One thing he mentioned is filtering out prefixes with excessively long AS paths, in their case paths longer than 40 AS hops.

There are a few best practices style documents that suggest this:

http://bgpfilterguide.nlnog.net/guides/long_paths/ <http://bgpfilterguide.nlnog.net/guides/long_paths/>

https://nsrc.org/workshops/2018/linx103-bgp/networking/peering-ixp/en/presentations/05-BGP-BCP.pdf <https://nsrc.org/workshops/2018/linx103-bgp/networking/peering-ixp/en/presentations/05-BGP-BCP.pdf>

My question: is rejecting excessively long AS paths something we want to do?

If so, I think it's important to publish a best practices document that creates clear expectations, so we avoid the situation where people prepend their paths, and then those paths are filtered by some ASes but not others.

Similar how there's a clear expectation that any IPv4 prefix of /24 or shorter will be accepted by all ASes but ones longer than /24 will not, /48 for IPv6.

FYI: the number of IPv4 paths with AS paths with 20 - 45 hops (with 45 being the maximum currently seen by Routeviews) is 0.04% of all 32 million paths.

Iljitsch

---

From: Aris Lambrianidis <[email-masked]>
Date: Mon, 16 Sep 2019 11:15:17 +0200

Hi Iljitsch,

This is somewhat alluded to in RFC 7454, section 9:

Network administrators SHOULD accept from customers only 2-byte or
      4-byte AS paths containing ASNs belonging to (or authorized to
      transit through) the customer.  If network administrators cannot
      build and generate filtering expressions to implement this, they
      SHOULD consider accepting only path lengths relevant to the type
      of customer they have (as in, if these customers are a leaf or
      have customers of their own) and SHOULD try to discourage
      excessive prepending in such paths.  This loose policy could be

Durand, et al.            Best Current Practice                [Page 18]
  <https://tools.ietf.org/html/rfc7454#page-19>
RFC 7454 <https://tools.ietf.org/html/rfc7454>                        BGP OPSEC                  February 2015

      combined with filters for specific 2-byte or 4-byte AS paths that
      must not be accepted if advertised by the customer, such as
      upstream transit providers or peer ASNs.
Kind regards,
Aris

> On 16 Sep 2019, at 10:21, Iljitsch van Beijnum <iljitsch=[email-masked]> wrote:
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow