Re: [GROW] Limiting AS path length?

[William Herrin]

On Mon, Sep 16, 2019 at 11:37 AM Job Snijders  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? :-)
>

Hi Job,

"Don't poke the bear," is generally good advice. When we have sufficient
reason to believe a particular behavior is error-prone, we should
discourage that behavior. Regardless of whose "fault" it is.

AND we should encourage folks to report and fix bugs.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Iljitsch van Beijnum]

FYI:

RouteViews data reveals the following:

- the longest AS path currently seen is 45 hops, 5 "real" hops and 40 prepends
- the longest unprepended path is 14 hops
- 99.95% of prefixes have an AS path are shorter than 20 hops
- if we remove prepends, 99.95% of prefixes have an AS path are shorter than 10 
hops

In theory, if two networks both have 45 hops, that could make the total 90 hops.

Also, if 14 hops all apply a completely reasonable three prepends, that's 56 
hops total.

In practice, if networks make sure to not add additional prepends for paths 
that are already very long, and make sure they're not unusually far from the 
DFZ core of the internet, a 50 hop limit should be safe today.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Claudio Jeker]

On Tue, Sep 17, 2019 at 11:36:18PM +, john heasley wrote:
> Mon, Sep 16, 2019 at 10:36:59PM +0200, Claudio Jeker:
> > > 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.
> 
> isnt this rfc7606

I only see input related checks in rfc7606 and there is nothing describing
what to do when the total lenght of an UPDATE exceeds 4096 bytes. At least
I did not spot it.

draft-ietf-idr-bgp-extended-messages-36 has a paragraph covering how to
handle oversized messages:

   A BGP speaker that has advertised the BGP Extended Message capability
   to its peers, may receive an UPDATE from one of its peers that
   produces an ongoing announcement that is larger than 4,096 octets.
   When propagating that UPDATE onward to a neighbor which has not
   advertised the BGP Extended Message capability, the speaker SHOULD
   try to reduce the outgoing message size by removing attributes
   eligible under the "attribute discard" approach of [RFC7606].  If the
   message is still too big, then it must not be sent to the neighbor
   ([RFC4271], Section 9.2).  Additionally, if the NLRI was previously
   advertised to that peer, it must be withdrawn from service
   ([RFC4271], Section 9.1.3).

Hopefully implementations will pick up this approach independent from the BGP
Extended Message Capability.

-- 
:wq Claudio

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[john heasley]

Mon, Sep 16, 2019 at 10:36:59PM +0200, Claudio Jeker:
> > 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.

isnt this rfc7606

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[UTTARO, JAMES]

+1

From: GROW  On Behalf Of Job Snijders
Sent: Monday, September 16, 2019 2:37 PM
To: Jared Mauch 
Cc: Iljitsch van Beijnum ; grow@ietf.org
Subject: Re: [GROW] Limiting AS path length?

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

Kind regards,

Job
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[David Farmer]

On Mon, Sep 16, 2019 at 11:47 AM Jeffrey Haas  wrote:

> Speaking as a vendor:
>


> With regard to memory use, it's not a real problem for implementations and
> is generally noise in the real world vs. the total number of paths in your
> router.
>

Yes, for a good implementation with sufficient memory, excessive path
length is probably noise. However, for a router already on the edge,
excessively long path can easily push it over the edge, along with a myriad
of other things of course.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[David Farmer]

On Mon, Sep 16, 2019 at 1:25 PM Jakob Heitz (jheitz) 
wrote:


> I'll add that Netflow can use the AS-PATH. When that option is used,
> the AS-PATH is downloaded to FIB, which is more constrained of memory than
> BGP is.
> I don't know what kinds of bugs could result from long AS-PATHs in Netflow
> collectors.
>

In the case I was referring to the netwflow collector also takes a BGP feed
from the router, to get BGP communities, full AS-Path, etc... It is was a
bug triggered buy long AS-Paths in this receive only BGP implementation
that caused us issues.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Joe Provo]

On Mon, Sep 16, 2019 at 11:43:06PM +0300, Nick Hilliard wrote:
[snip]
> If people want to shoot themselves in the foot, then they should be 
> given plenty of leeway to do so.  There's no reason to draw a line at 
> the ietf for this sort of thing.
> https://www.ietf.org/mailman/listinfo/grow

+100

I've had to filter dump prepends back in the day when 50+
would clobber a Certain vendor's platform. If some operations 
fora wish to publish BCPs regarding ridiculous prepends, that's 
a different kettle of fish. 

Cheers,

Joe

-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Nick Hilliard]

Iljitsch van Beijnum wrote on 16/09/2019 22:54:

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?
why do you assume someone else will care if you lose connectivity 
because you've done something obviously pointless?


Small prepends can influence traffic engineering.  Large prepends won't 
make any more difference.  Gigantic prepends cause operators to roll 
their eyes, if they bother to look for this sort of thing - which they 
rarely do.


If people want to shoot themselves in the foot, then they should be 
given plenty of leeway to do so.  There's no reason to draw a line at 
the ietf for this sort of thing.


Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Claudio Jeker]

On Mon, Sep 16, 2019 at 09:54:36PM +0200, Iljitsch van Beijnum wrote:
> On 16 Sep 2019, at 20:37, Job Snijders  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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Iljitsch van Beijnum]

On 16 Sep 2019, at 20:37, Job Snijders  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.

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?

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.)
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Job Snijders]

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

Kind regards,

Job
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Jared Mauch]

Operator here.

We have limitations around 128 to avoid some vendor bugs. I suspect we could 
remove them but people with mental histories of pain always worry about that 
change. 

Sent from my iStarship

> On Sep 16, 2019, at 12:42 PM, Jeffrey Haas  wrote:
> 
> Speaking as a vendor:
> 
> 
>> On Sep 16, 2019, at 11:18 AM, David Farmer  wrote:
>>> On Mon, Sep 16, 2019 at 8:25 AM Job Snijders  wrote:
>>> Can we articulate what problem is solved by limiting the AS_PATH length?
>> 
>> I'm aware of a Netflow tool that crashes when it receives BGP paths that are 
>> excessively long.  Furthermore, excessively long paths will use more memory 
>> which could cause stability issues in some situations.
> 
> There are a number of bugs in implementations over the life of BGP related to 
> path length.  In particular, overflows either in the number of ASes in the 
> segment (max 255), where a second segment needs to be created; overflows in 
> the length of the path attribute and needing to switch the size of the length 
> field (the extended bit).
> 
> This is the primary reason we've tended to see strong pushes for filter 
> length - attempts to avoid exercising such bugs.  Ideally, implementations 
> should have been upgraded to avoid them by this point.
> 
> I am not optimistic. :-)
> 
> With regard to memory use, it's not a real problem for implementations and is 
> generally noise in the real world vs. the total number of paths in your 
> router.
> 
>> 
>> Having a sanity limit on path length isn't a bad idea. Personally, I think 
>> 20 a little on the short side, but 40 or 50 seems like a reasonable limit. 
>> Anything beyond that is most definitely excessive, and I'm not sure you 
>> would even want to use such a path if it were real.
> 
> Quoting a coworker: constants are almost always wrong. :-)
> 
> -- Jeff
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Jakob Heitz (jheitz)]

I agree with Jeff.
Not that Cisco has these bugs :)
Just kidding Jeff, I take your point.
Cisco once had a bug at 255. It's long been fixed.

I'll add that Netflow can use the AS-PATH. When that option is used,
the AS-PATH is downloaded to FIB, which is more constrained of memory than BGP 
is.
I don't know what kinds of bugs could result from long AS-PATHs in Netflow 
collectors.

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of Jeffrey Haas
Sent: Monday, September 16, 2019 9:43 AM
To: David Farmer 
Cc: Iljitsch van Beijnum ; grow@ietf.org
Subject: Re: [GROW] Limiting AS path length?

Speaking as a vendor:


> On Sep 16, 2019, at 11:18 AM, David Farmer  wrote:
> On Mon, Sep 16, 2019 at 8:25 AM Job Snijders  wrote:
>> Can we articulate what problem is solved by limiting the AS_PATH length?
> 
> I'm aware of a Netflow tool that crashes when it receives BGP paths that are 
> excessively long.  Furthermore, excessively long paths will use more memory 
> which could cause stability issues in some situations.

There are a number of bugs in implementations over the life of BGP related to 
path length.  In particular, overflows either in the number of ASes in the 
segment (max 255), where a second segment needs to be created; overflows in the 
length of the path attribute and needing to switch the size of the length field 
(the extended bit).

This is the primary reason we've tended to see strong pushes for filter length 
- attempts to avoid exercising such bugs.  Ideally, implementations should have 
been upgraded to avoid them by this point.

I am not optimistic. :-)

With regard to memory use, it's not a real problem for implementations and is 
generally noise in the real world vs. the total number of paths in your router.

> 
> Having a sanity limit on path length isn't a bad idea. Personally, I think 20 
> a little on the short side, but 40 or 50 seems like a reasonable limit. 
> Anything beyond that is most definitely excessive, and I'm not sure you would 
> even want to use such a path if it were real.

Quoting a coworker: constants are almost always wrong. :-)

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Jeffrey Haas]

Speaking as a vendor:


> On Sep 16, 2019, at 11:18 AM, David Farmer  wrote:
> On Mon, Sep 16, 2019 at 8:25 AM Job Snijders  wrote:
>> Can we articulate what problem is solved by limiting the AS_PATH length?
> 
> I'm aware of a Netflow tool that crashes when it receives BGP paths that are 
> excessively long.  Furthermore, excessively long paths will use more memory 
> which could cause stability issues in some situations.

There are a number of bugs in implementations over the life of BGP related to 
path length.  In particular, overflows either in the number of ASes in the 
segment (max 255), where a second segment needs to be created; overflows in the 
length of the path attribute and needing to switch the size of the length field 
(the extended bit).

This is the primary reason we've tended to see strong pushes for filter length 
- attempts to avoid exercising such bugs.  Ideally, implementations should have 
been upgraded to avoid them by this point.

I am not optimistic. :-)

With regard to memory use, it's not a real problem for implementations and is 
generally noise in the real world vs. the total number of paths in your router.

> 
> Having a sanity limit on path length isn't a bad idea. Personally, I think 20 
> a little on the short side, but 40 or 50 seems like a reasonable limit. 
> Anything beyond that is most definitely excessive, and I'm not sure you would 
> even want to use such a path if it were real.

Quoting a coworker: constants are almost always wrong. :-)

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Iljitsch van Beijnum]

On 16 Sep 2019, at 18:03, john heasley  wrote:

>> Furthermore, excessively long paths will use more memory

> Not significantly.  It is not length that represents large consumption
> by AS-PATHs, its variance of paths in the RIB.  ie: no sane
> implementation copies the path to every RIB entry, its a pointer/reference.

An extra AS hop takes six bytes on the wire: two for the 16-bit AS path and 
four for the 32-bit AS path.

AS path prepending (all of it, not just the excessive stuff) increases the 
average AS path length by 0.4 - 0.5, that's about 15% (something like 3.5 -> 
3.9 / 4.1 -> 4.6, depending on your vantage point).

Iljitsch
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[john heasley]

Mon, Sep 16, 2019 at 10:18:09AM -0500, David Farmer:
> Furthermore, excessively long paths will use more memory

Not significantly.  It is not length that represents large consumption
by AS-PATHs, its variance of paths in the RIB.  ie: no sane
implementation copies the path to every RIB entry, its a pointer/reference.

1 transit 1 ibgp: 185637 BGP AS-PATH entries using 8.8M
2 transits: 338034 BGP AS-PATH entries using 16.5M
1 transit 47 peers: 299673 BGP AS-PATH entries using 15M

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[David Farmer]

On Mon, Sep 16, 2019 at 8:25 AM Job Snijders  wrote:

> On Mon, Sep 16, 2019 at 16:19 John Kristoff  wrote:
>
>> On Mon, 16 Sep 2019 08:21:08 +
>> Iljitsch van Beijnum  wrote:
>>
>> > Dear Global Routing Operators,
>>
>> And medium-size academic netop.
>>
>> > My question: is rejecting excessively long AS paths something we want
>> > to do?
>>
>> It is something I've decided to do.  When I looked at the paths we were
>> getting a few months back I decided to drop at 20.  I've pointed people
>> to my template doc so it is possible that others may have done this as
>> well.
>
>
>
> Can we articulate what problem is solved by limiting the AS_PATH length?
>
> Kind regards,
>
> Job
>

I'm aware of a Netflow tool that crashes when it receives BGP paths that
are excessively long.  Furthermore, excessively long paths will use more
memory which could cause stability issues in some situations.

Having a sanity limit on path length isn't a bad idea. Personally, I think
20 a little on the short side, but 40 or 50 seems like a reasonable limit.
Anything beyond that is most definitely excessive, and I'm not sure you
would even want to use such a path if it were real.

 thanks

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Job Snijders]

On Mon, Sep 16, 2019 at 16:19 John Kristoff  wrote:

> On Mon, 16 Sep 2019 08:21:08 +
> Iljitsch van Beijnum  wrote:
>
> > Dear Global Routing Operators,
>
> And medium-size academic netop.
>
> > My question: is rejecting excessively long AS paths something we want
> > to do?
>
> It is something I've decided to do.  When I looked at the paths we were
> getting a few months back I decided to drop at 20.  I've pointed people
> to my template doc so it is possible that others may have done this as
> well.



Can we articulate what problem is solved by limiting the AS_PATH length?

Kind regards,

Job

>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[John Kristoff]

On Mon, 16 Sep 2019 08:21:08 +
Iljitsch van Beijnum  wrote:

> Dear Global Routing Operators,

And medium-size academic netop.

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

It is something I've decided to do.  When I looked at the paths we were
getting a few months back I decided to drop at 20.  I've pointed people
to my template doc so it is possible that others may have done this as
well.

  

John

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[Aris Lambrianidis]

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]
  
RFC 7454 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 
>  wrote:
> 
> 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/ 
> 
> 
> 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
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow



signature.asc
Description: Message signed with OpenPGP
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Limiting AS path length?

[Iljitsch van Beijnum]

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/ 


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___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow