Re: Smaller than a /24 for BGP?

[Masataka Ohta]

Michael Bolton via NANOG wrote:

> We would benefit from advertising /25's but it hurt's more
> than it helps.

That is, IPv6 really hurts.


I'm in the alarm industry and they still haven't started adopting
IPv6. If we allow /25 subnets, some industries will never change. In
a sense, we have to “force” them to change.


FYI, WRT routing table bloat, IPv6 having a lot longer minimum
allocation prefix than /24 (which forbid operators cut IPv6
prefixes longer than /24), that is, a lot beyond direct SRAM
look up, and, worse, needing longer TCAM word size (64 or 128
bits?) than IPv4, is, in a not so long run, a lot lot worse
than IPv4.

Masataka Ohta

RE: Smaller than a /24 for BGP?

[Michael Bolton via NANOG]

I’m late to the conversation, but I would have to agree with most. Below a /24 
route advertisement shouldn’t happen.

I have a /24 that I would love to advertise as 2 /25’s, but the affects on 
everyone else is just too much. I take full routes from 4 providers, and I 
certainly don’t want to add over 100K. Carriers and enterprises have to pay a 
lot for our edge routers doing bgp and most don’t want to upgrade. We would 
benefit from advertising /25’s but it hurt’s more than it helps.

I’m in the alarm industry and they still haven’t started adopting IPv6. If we 
allow /25 subnets, some industries will never change. In a sense, we have to 
“force” them to change.

Mike



From: NANOG  On 
Behalf Of Mike Hammett
Sent: Thursday, January 26, 2023 8:52 AM
To: Chris 
Cc: nanog@nanog.org
Subject: Re: Smaller than a /24 for BGP?


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.
Implementing v6 is important, but unrelated to allowing smaller v4 prefixes.

Not taking a position either way if smaller v4 prefixes is good or bad.


-
Mike Hammett
Intelligent Computing Solutions<http://www.ics-il.com/>
[http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/ICSIL>[http://www.ics-il.com/images/googleicon.png]<https://plus.google.com/+IntelligentComputingSolutionsDeKalb>[http://www.ics-il.com/images/linkedinicon.png]<https://www.linkedin.com/company/intelligent-computing-solutions>[http://www.ics-il.com/images/twittericon.png]<https://twitter.com/ICSIL>
Midwest Internet Exchange<http://www.midwest-ix.com/>
[http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/mdwestix>[http://www.ics-il.com/images/linkedinicon.png]<https://www.linkedin.com/company/midwest-internet-exchange>[http://www.ics-il.com/images/twittericon.png]<https://twitter.com/mdwestix>
The Brothers WISP<http://www.thebrotherswisp.com/>
[http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/thebrotherswisp>[http://www.ics-il.com/images/youtubeicon.png]<https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>

From: "Chris" mailto:ch...@noskillz.com>>
To: "Justin Wilson (Lists)" mailto:li...@mtin.net>>
Cc: nanog@nanog.org<mailto:nanog@nanog.org>
Sent: Wednesday, January 25, 2023 2:24:29 PM
Subject: Re: Smaller than a /24 for BGP?
I would suggest that this is trying to solve the wrong problem.  To me this is 
pressure to migrate to v6, not alter routing rules.

Kind Regards,
Chris Haun

On Tue, Jan 24, 2023 at 12:21 PM Justin Wilson (Lists) 
mailto:li...@mtin.net>> wrote:
Have there been talks about the best practices to accept things smaller than a 
/24? I qm seeing more and more scenarios where folks need to participate in BGP 
but they do not need a full /24 of space.  Seems wasteful.  I know this would 
bloat the routing table immensely.  I know of several folks who could split 
their /24 into /25s across a few regions and still have plenty of IP space.



Justin Wilson
j...@j2sw.com<mailto:j...@j2sw.com>

—
https://blog.j2sw.com - Podcast and Blog
https://www.fd-ix.com

IMPORTANT NOTICE: This e-mail message is intended to be received only by 
persons entitled to receive the confidential information it may contain. E-mail 
messages to clients of Holmes Security Systems may contain information that is 
confidential and legally privileged. Please do not read, copy, forward, or 
store this message unless you are an intended recipient of it. If you have 
received this message in error, please forward it to the sender and delete it 
completely from your computer system.

RE: Smaller than a /24 for BGP?

[Mike Hammett]

I suspect the initial question was related to scarcity and not traffic 
engineering.

-Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe 
Brothers WISP

- Original Message -
From: Michael Bolton 
To: Mike Hammett , Chris 
Cc: nanog@nanog.org
Sent: Sat, 04 Feb 2023 19:50:07 -0600 (CST)
Subject: RE: Smaller than a /24 for BGP?

I’m late to the conversation, but I would have to agree with most. Below a /24 
route advertisement shouldn’t happen.

I have a /24 that I would love to advertise as 2 /25’s, but the affects on 
everyone else is just too much. I take full routes from 4 providers, and I 
certainly don’t want to add over 100K. Carriers and enterprises have to pay a 
lot for our edge routers doing bgp and most don’t want to upgrade. We would 
benefit from advertising /25’s but it hurt’s more than it helps.

I’m in the alarm industry and they still haven’t started adopting IPv6. If we 
allow /25 subnets, some industries will never change. In a sense, we have to 
“force” them to change.

Mike



From: NANOG  On 
Behalf Of Mike Hammett
Sent: Thursday, January 26, 2023 8:52 AM
To: Chris 
Cc: nanog@nanog.org
Subject: Re: Smaller than a /24 for BGP?


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.
Implementing v6 is important, but unrelated to allowing smaller v4 prefixes.

Not taking a position either way if smaller v4 prefixes is good or bad.


-
Mike Hammett
Intelligent Computing Solutions<http://www.ics-il.com/>
[http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/ICSIL>[http://www.ics-il.com/images/googleicon.png]<https://plus.google.com/+IntelligentComputingSolutionsDeKalb>[http://www.ics-il.com/images/linkedinicon.png]<https://www.linkedin.com/company/intelligent-computing-solutions>[http://www.ics-il.com/images/twittericon.png]<https://twitter.com/ICSIL>
Midwest Internet Exchange<http://www.midwest-ix.com/>
[http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/mdwestix>[http://www.ics-il.com/images/linkedinicon.png]<https://www.linkedin.com/company/midwest-internet-exchange>[http://www.ics-il.com/images/twittericon.png]<https://twitter.com/mdwestix>
The Brothers WISP<http://www.thebrotherswisp.com/>
[http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/thebrotherswisp>[http://www.ics-il.com/images/youtubeicon.png]<https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>

From: "Chris" mailto:ch...@noskillz.com>>
To: "Justin Wilson (Lists)" mailto:li...@mtin.net>>
Cc: nanog@nanog.org<mailto:nanog@nanog.org>
Sent: Wednesday, January 25, 2023 2:24:29 PM
Subject: Re: Smaller than a /24 for BGP?
I would suggest that this is trying to solve the wrong problem.  To me this is 
pressure to migrate to v6, not alter routing rules.

Kind Regards,
Chris Haun

On Tue, Jan 24, 2023 at 12:21 PM Justin Wilson (Lists) 
mailto:li...@mtin.net>> wrote:
Have there been talks about the best practices to accept things smaller than a 
/24? I qm seeing more and more scenarios where folks need to participate in BGP 
but they do not need a full /24 of space.  Seems wasteful.  I know this would 
bloat the routing table immensely.  I know of several folks who could split 
their /24 into /25s across a few regions and still have plenty of IP space.



Justin Wilson
j...@j2sw.com<mailto:j...@j2sw.com>

—
https://blog.j2sw.com - Podcast and Blog
https://www.fd-ix.com

IMPORTANT NOTICE: This e-mail message is intended to be received only by 
persons entitled to receive the confidential information it may contain. E-mail 
messages to clients of Holmes Security Systems may contain information that is 
confidential and legally privileged. Please do not read, copy, forward, or 
store this message unless you are an intended recipient of it. If you have 
received this message in error, please forward it to the sender and delete it 
completely from your computer system.

Re: ROV concern for hyper-specific prefixes (renamed from `Re: Smaller than a /24 for BGP?')

[Amir Herzberg]

Tom, thanks. I forget to mention the problem of this case ( AS 10 creates
an ROA for X.X.X.X/24 , maxLength 28). Security-wise, this may actually be
the worst solution:
- An attacker can abuse this ROA to perform origin-hijack of the /28
subprefix, just like the origin hijack if AS 10 publishes ROA for the /28
- The max-length also allows similar origin-hijack of `intermediate
prefixes' (e.g., /25), which may be allowed by ASes which will not allow
/28, so there may be an even higher chance for the attacker to succeed in
attracting traffic.

Of course, this is basically what is discussed in the `maxlength considered
harmful' paper and RFC (RFC 9319), nothing really new here.

Best, Amir
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
https://sites.google.com/site/amirherzberg/cybersecurity




On Mon, Jan 30, 2023 at 9:39 AM Tom Beecher  wrote:

> - If origin makes a ROA only for covering prefix (say /24) then the /28
>> announcement would be considered invalid by ROV and (even more likely)
>> dropped. Also you get more instances of `invalid' announcements, making
>> adoption of ROVs and ROAs harder.
>>
>
> AS 10 creates an ROA for X.X.X.X/24 , maxLength 28. This means AS10 can
> announce any /28 in that /24, and any validator should return valid. (This
> ignores if the longer than /24s would be accepted by policy or not. )
>
> On Mon, Jan 30, 2023 at 9:19 AM Amir Herzberg 
> wrote:
>
>> Thanks to Lars for this interesting input and results (which I wasn't
>> familiar with).
>>
>> I want to mention another concern with the possible use of hyper-specific
>> IP prefixes, i.e., longer than /24, which I haven't seen discussed in the
>> thread (maybe I missed it?). Namely, if you allow say /28 announcements,
>> then what would be the impact of ROV? Seems this can cause few problems:
>>
>> - If origin, say AS 10, makes a ROA for the /28, this would allow an
>> attacker, e.g., AS 666,  to do origin-hijack (announce path 666-10 to the
>> /28), and attract traffic for the /28 from anybody accepting /28
>> announcements (that didn't receive the legit announcement). Plus, of
>> course, you get more overhead in ROA distribution and validation.
>>
>> - If origin makes a ROA only for covering prefix (say /24) then the /28
>> announcement would be considered invalid by ROV and (even more likely)
>> dropped. Also you get more instances of `invalid' announcements, making
>> adoption of ROVs and ROAs harder.
>>
>> Just a thought... Amir
>> --
>> Amir Herzberg
>>
>> Comcast professor of Security Innovations, Computer Science and
>> Engineering, University of Connecticut
>> Homepage: https://sites.google.com/site/amirherzberg/home
>> `Applied Introduction to Cryptography' textbook and lectures:
>> https://sites.google.com/site/amirherzberg/cybersecurity
>>
>>
>>
>>
>> On Wed, Jan 25, 2023 at 1:17 PM Lars Prehn  wrote:
>>
>>> We performed some high-level analyses on these hyper-specific prefixes
>>> about a year ago and pushed some insights into a blog post [1] and a paper
>>> [2].
>>>
>>> While not many ASes redistribute these prefixes, some accept and use
>>> them for their internal routing (e.g., NTT's IPv4 filtering policy [3]).
>>> Rob already pointed out that this is often sufficient for many traffic
>>> engineering tasks. In the remaining scenarios, announcing a covering /24
>>> and hyper-specific prefixes may result in some traffic engineering, even if
>>> the predictability of the routing impact is closer to path prepending than
>>> usual more-specific announcements. In contrast to John's claim, some
>>> transit ASes explicitly enabled redistributions of up to /28s for their
>>> customers upon request (at least, they told us so during interviews).
>>>
>>> Accepting and globally redistributing all hyper-specifics increases the
>>> routing table size by >100K routes (according to what route collectors
>>> see). There are also about 2-4 de-aggregation events every year in which
>>> some origin (accidentally) leaks some large number of hyper-specifics to
>>> its neighbours for a short time.
>>>
>>> Best regards,
>>> Lars
>>>
>>> [1]
>>> https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-wild/
>>> [2] https://dl.acm.org/doi/pdf/10.1145/3544912.3544916
>>> [3] https://www.gin.ntt.net/support-center/policies-procedures/routing/
>>>
>>>
>>> On 25.01.23 05:12, Forrest Christian (List Account) wrote:
>>>
>>> I have two thoughts in relation to this:
>>>
>>> 1) It's amazing how many threads end up ending in the (correct) summary
>>> that making an even minor global change to the way the internet works
>>> and/or is configured to enable some potentially useful feature isn't likely
>>> to happen.
>>>
>>> 2) I'd really like to be able to tag a BGP announcement with "only use
>>> this announcement as an absolute last 

Re: ROV concern for hyper-specific prefixes (renamed from `Re: Smaller than a /24 for BGP?')

[Tom Beecher]

>
> - If origin makes a ROA only for covering prefix (say /24) then the /28
> announcement would be considered invalid by ROV and (even more likely)
> dropped. Also you get more instances of `invalid' announcements, making
> adoption of ROVs and ROAs harder.
>

AS 10 creates an ROA for X.X.X.X/24 , maxLength 28. This means AS10 can
announce any /28 in that /24, and any validator should return valid. (This
ignores if the longer than /24s would be accepted by policy or not. )

On Mon, Jan 30, 2023 at 9:19 AM Amir Herzberg  wrote:

> Thanks to Lars for this interesting input and results (which I wasn't
> familiar with).
>
> I want to mention another concern with the possible use of hyper-specific
> IP prefixes, i.e., longer than /24, which I haven't seen discussed in the
> thread (maybe I missed it?). Namely, if you allow say /28 announcements,
> then what would be the impact of ROV? Seems this can cause few problems:
>
> - If origin, say AS 10, makes a ROA for the /28, this would allow an
> attacker, e.g., AS 666,  to do origin-hijack (announce path 666-10 to the
> /28), and attract traffic for the /28 from anybody accepting /28
> announcements (that didn't receive the legit announcement). Plus, of
> course, you get more overhead in ROA distribution and validation.
>
> - If origin makes a ROA only for covering prefix (say /24) then the /28
> announcement would be considered invalid by ROV and (even more likely)
> dropped. Also you get more instances of `invalid' announcements, making
> adoption of ROVs and ROAs harder.
>
> Just a thought... Amir
> --
> Amir Herzberg
>
> Comcast professor of Security Innovations, Computer Science and
> Engineering, University of Connecticut
> Homepage: https://sites.google.com/site/amirherzberg/home
> `Applied Introduction to Cryptography' textbook and lectures:
> https://sites.google.com/site/amirherzberg/cybersecurity
>
>
>
>
> On Wed, Jan 25, 2023 at 1:17 PM Lars Prehn  wrote:
>
>> We performed some high-level analyses on these hyper-specific prefixes
>> about a year ago and pushed some insights into a blog post [1] and a paper
>> [2].
>>
>> While not many ASes redistribute these prefixes, some accept and use them
>> for their internal routing (e.g., NTT's IPv4 filtering policy [3]). Rob
>> already pointed out that this is often sufficient for many traffic
>> engineering tasks. In the remaining scenarios, announcing a covering /24
>> and hyper-specific prefixes may result in some traffic engineering, even if
>> the predictability of the routing impact is closer to path prepending than
>> usual more-specific announcements. In contrast to John's claim, some
>> transit ASes explicitly enabled redistributions of up to /28s for their
>> customers upon request (at least, they told us so during interviews).
>>
>> Accepting and globally redistributing all hyper-specifics increases the
>> routing table size by >100K routes (according to what route collectors
>> see). There are also about 2-4 de-aggregation events every year in which
>> some origin (accidentally) leaks some large number of hyper-specifics to
>> its neighbours for a short time.
>>
>> Best regards,
>> Lars
>>
>> [1]
>> https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-wild/
>> [2] https://dl.acm.org/doi/pdf/10.1145/3544912.3544916
>> [3] https://www.gin.ntt.net/support-center/policies-procedures/routing/
>>
>>
>> On 25.01.23 05:12, Forrest Christian (List Account) wrote:
>>
>> I have two thoughts in relation to this:
>>
>> 1) It's amazing how many threads end up ending in the (correct) summary
>> that making an even minor global change to the way the internet works
>> and/or is configured to enable some potentially useful feature isn't likely
>> to happen.
>>
>> 2) I'd really like to be able to tag a BGP announcement with "only use
>> this announcement as an absolute last resort" so I don't have to break my
>> prefixes in half in those cases where I have a backup path that needs to
>> only be used as a last resort.  (Today each prefix I have to do this with
>> results in 3 prefixes in the table where one would do).
>>
>> And yes. I know #2 is precluded from actually ever happening because of
>> #1.   The irony is not lost on me.
>>
>>
>> On Tue, Jan 24, 2023, 7:54 PM John Levine  wrote:
>>
>>> It appears that Chris J. Ruschmann  said:
>>> >-=-=-=-=-=-
>>> >How do you plan on getting rid of all the filters that don’t accept
>>> anything less than a /24?
>>> >
>>> >In all seriousness If I have these, I’d imagine everyone else does too.
>>>
>>> Right. Since the Internet has no settlements, there is no way to
>>> persuade a network of whom you are not a customer to accept your
>>> announcements if they don't want to, and even for the largest
>>> networks, that is 99% of the other networks in the world. So no,
>>> they're not going to accept your /25 no matter how deeply you believe
>>> that they should.
>>>
>>> I'm kind of surprised that we haven't seen pushback against sloppily
>>> disaggregated 

ROV concern for hyper-specific prefixes (renamed from `Re: Smaller than a /24 for BGP?')

[Amir Herzberg]

Thanks to Lars for this interesting input and results (which I wasn't
familiar with).

I want to mention another concern with the possible use of hyper-specific
IP prefixes, i.e., longer than /24, which I haven't seen discussed in the
thread (maybe I missed it?). Namely, if you allow say /28 announcements,
then what would be the impact of ROV? Seems this can cause few problems:

- If origin, say AS 10, makes a ROA for the /28, this would allow an
attacker, e.g., AS 666,  to do origin-hijack (announce path 666-10 to the
/28), and attract traffic for the /28 from anybody accepting /28
announcements (that didn't receive the legit announcement). Plus, of
course, you get more overhead in ROA distribution and validation.

- If origin makes a ROA only for covering prefix (say /24) then the /28
announcement would be considered invalid by ROV and (even more likely)
dropped. Also you get more instances of `invalid' announcements, making
adoption of ROVs and ROAs harder.

Just a thought... Amir
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
https://sites.google.com/site/amirherzberg/cybersecurity




On Wed, Jan 25, 2023 at 1:17 PM Lars Prehn  wrote:

> We performed some high-level analyses on these hyper-specific prefixes
> about a year ago and pushed some insights into a blog post [1] and a paper
> [2].
>
> While not many ASes redistribute these prefixes, some accept and use them
> for their internal routing (e.g., NTT's IPv4 filtering policy [3]). Rob
> already pointed out that this is often sufficient for many traffic
> engineering tasks. In the remaining scenarios, announcing a covering /24
> and hyper-specific prefixes may result in some traffic engineering, even if
> the predictability of the routing impact is closer to path prepending than
> usual more-specific announcements. In contrast to John's claim, some
> transit ASes explicitly enabled redistributions of up to /28s for their
> customers upon request (at least, they told us so during interviews).
>
> Accepting and globally redistributing all hyper-specifics increases the
> routing table size by >100K routes (according to what route collectors
> see). There are also about 2-4 de-aggregation events every year in which
> some origin (accidentally) leaks some large number of hyper-specifics to
> its neighbours for a short time.
>
> Best regards,
> Lars
>
> [1]
> https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-wild/
> [2] https://dl.acm.org/doi/pdf/10.1145/3544912.3544916
> [3] https://www.gin.ntt.net/support-center/policies-procedures/routing/
>
>
> On 25.01.23 05:12, Forrest Christian (List Account) wrote:
>
> I have two thoughts in relation to this:
>
> 1) It's amazing how many threads end up ending in the (correct) summary
> that making an even minor global change to the way the internet works
> and/or is configured to enable some potentially useful feature isn't likely
> to happen.
>
> 2) I'd really like to be able to tag a BGP announcement with "only use
> this announcement as an absolute last resort" so I don't have to break my
> prefixes in half in those cases where I have a backup path that needs to
> only be used as a last resort.  (Today each prefix I have to do this with
> results in 3 prefixes in the table where one would do).
>
> And yes. I know #2 is precluded from actually ever happening because of
> #1.   The irony is not lost on me.
>
>
> On Tue, Jan 24, 2023, 7:54 PM John Levine  wrote:
>
>> It appears that Chris J. Ruschmann  said:
>> >-=-=-=-=-=-
>> >How do you plan on getting rid of all the filters that don’t accept
>> anything less than a /24?
>> >
>> >In all seriousness If I have these, I’d imagine everyone else does too.
>>
>> Right. Since the Internet has no settlements, there is no way to
>> persuade a network of whom you are not a customer to accept your
>> announcements if they don't want to, and even for the largest
>> networks, that is 99% of the other networks in the world. So no,
>> they're not going to accept your /25 no matter how deeply you believe
>> that they should.
>>
>> I'm kind of surprised that we haven't seen pushback against sloppily
>> disaggregated announcements.  It is my impression that the route table
>> would be appreciably smaller if a few networks combined adjacent a
>> bunch of /24's into larger blocks.
>>
>> R's,
>> John
>>
>

Re: Smaller than a /24 for BGP?

[Masataka Ohta]

I wrote:


So,
another way of multihoming critically depends on replacing the layer-4
protocols with something that doesn't intermingle the IP address with
the connection identifier.


Wrong. As is stated in my ID that:

    On the other hand, with end to end multihoming, multihoming is
    supported by transport (TCP) or application layer (UDP etc.) of end
    systems and does not introduce any problem in the network and works
    as long as there is some connectivity between the end systems.

end to end multihoming may be supported at the application layer
by trying all the available addresses, which is what DNS and
SMTP are actually doing.


To my surprise, I've found that the current (2017) happy eyeball
already does so as is stated in rfc8305:

: Appendix A.  Differences from RFC 6555
:o  how to handle multiple addresses from each address family

So, we are ready for end to end multihoming for which multiple
PA addresses are enough and /24 is not necessary. Though
not all the application protocols may support it, DNS, SMTP
and HTTP(S) should be good enough as a starter.

It should be noted that happy eyeball strongly depends on
DNS, even though someone might think DNS not guaranteed.

Your web server is multihomed if you assign it PA
addresses assigned from multiple ISPs and register
the addresses to DNS. You don't have to manage BGP.


TCP modification is just an option useful for long lasting
TCP connections.


A major obstacle for it, as most of you can see, is that there
are people who can't distinguish IP address changes by mobility
and by multihoming. Such people will keep reinventing MPTCP.

Masataka Ohta

Re: Smaller than a /24 for BGP?

[William Herrin]

On Sat, Jan 28, 2023 at 11:06 PM Masataka Ohta
 wrote:
> William Herrin wrote:
>  > Moreover, the DNS does guarantee
>  > its information to be correct until the TTL expires, making it
>  > unsuitable for communicating address information which may change
>  > sooner.
>
> I'm afraid you know very little about DNS operation.

How do you expect to improve your draft if you don't listen when
people tell you you've screwed something up?

-Bill Herrin


-- 
For hire. https://bill.herrin.us/resume/

Re: Smaller than a /24 for BGP?

[Masataka Ohta]

William Herrin wrote:


 The easiest way for applications know all the addresses of the
 destination is to use DNS. With DNS reverse, followed by forward,
 lookup, applications can get a list of all the addresses of the
 destination from an address of the destination.


The DNS provides no such guarantee.


Guarantee for what?

Remember that we have been enjoying secure confirmation that
certain IP address belongs to certain hostname by DNS reverse
look up without any guarantee.

> Moreover, the DNS does guarantee
> its information to be correct until the TTL expires, making it
> unsuitable for communicating address information which may change
> sooner.

I'm afraid you know very little about DNS operation. See rfc1034:

   If a change can be anticipated, the TTL can be reduced prior
   to the change to minimize inconsistency during the change,
   and then increased back to its former value following the
   change.

which is the way to operate DNS when host addresses are changing,
for example, by multihoming configuration changes.

In addition, when a dual homed site with end to end multihoming
changes one of its ISP, it is a good idea to offer all the three
addresses by DNS during the change. Make before break.


 With TCP, applications must be able to pass multiple addresses to
 transport layer (e.g. BSD socket).

which implies addresses are supplied from applications by
DNS look up.


Which is a bit of hand-waving since the protocol can't do anything
with that information regardless of whether you expand the API to
provide it.


Read my draft, which explains how TCP should be modified.

Masataka Ohta

Re: Smaller than a /24 for BGP?

[William Herrin]

On Sat, Jan 28, 2023 at 5:48 PM Masataka Ohta
 wrote:
> The following way in my ID:
>
> The easiest way for applications know all the addresses of the
> destination is to use DNS. With DNS reverse, followed by forward,
> lookup, applications can get a list of all the addresses of the
> destination from an address of the destination.

The DNS provides no such guarantee. Moreover, the DNS does guarantee
its information to be correct until the TTL expires, making it
unsuitable for communicating address information which may change
sooner.


> As for (long lasting) TCP, my ID says:
>
> With TCP, applications must be able to pass multiple addresses to
> transport layer (e.g. BSD socket).
>
> which implies addresses are supplied from applications by
> DNS look up.

Which is a bit of hand-waving since the protocol can't do anything
with that information regardless of whether you expand the API to
provide it. Even if it could, you  also miss the point that the
information -may change- during the ongoing connection so you can't
just statically retrieve it.

Regards,
Bill Herrin


-- 
For hire. https://bill.herrin.us/resume/

Re: Smaller than a /24 for BGP?

[Masataka Ohta]

William Herrin wrote:


Use Multipath TCP
https://datatracker.ietf.org/group/mptcp/documents/


Doesn't work well. Has security problems (mismatch between reported IP
addresses used and actual addresses in use) and it can't reacquire the
opposing endpoint if an address is lost before a new one is
communicated.


It merely means MPTCP is wrongly architected. Dynamically changing
IP addresses is for mobility (if you don't mind location privacy),
not for multihoming.

The following way in my ID:

   The easiest way for applications know all the addresses of the
   destination is to use DNS. With DNS reverse, followed by forward,
   lookup, applications can get a list of all the addresses of the
   destination from an address of the destination.

does not have any such problem and should be as safe as
happy eyeball for two or more IPv4/IPv6 addresses.

As for (long lasting) TCP, my ID says:

   With TCP, applications must be able to pass multiple addresses to
   transport layer (e.g. BSD socket).

which implies addresses are supplied from applications by
DNS look up.

Though a client may, at the time TCP connection is established,
send a list of its IP addresses to a server, which may have some
security complications, it is simpler to let the server just
rely on DNS:

   With DNS reverse, followed by forward,
   lookup, applications can get a list of all the addresses of the
   destination from an address of the destination.

As I pointed out in the previous mail, DNS already supports
end to end multihoming at the application layer to try all
the addresses of name servers, on which other applications
can safely rely.

Masataka Ohta

Re: Smaller than a /24 for BGP?

[Masataka Ohta]

William Herrin wrote:


That multihomed sites are relying on the entire Internet
for computation of the best ways to reach them is not
healthy way of multihoming.


This was studied in the IRTF RRG about a decade ago. There aren't any

> other workable ways of multihoming compatible with the TCP protocol,
> not even in theory.

A decade? The problem and the solution was thoroughly studied by me
long ago and the first ID was available already in 2000.

The 5th version is here:

https://datatracker.ietf.org/doc/html/draft-ohta-e2e-multihoming-05.txt

I've found that you can access the first one by "Compare
versions" feature of the web page.


So,
another way of multihoming critically depends on replacing the layer-4
protocols with something that doesn't intermingle the IP address with
the connection identifier.


Wrong. As is stated in my ID that:

   On the other hand, with end to end multihoming, multihoming is
   supported by transport (TCP) or application layer (UDP etc.) of end
   systems and does not introduce any problem in the network and works
   as long as there is some connectivity between the end systems.

end to end multihoming may be supported at the application layer
by trying all the available addresses, which is what DNS and
SMTP are actually doing.

TCP modification is just an option useful for long lasting
TCP connections.

Masataka Ohta

Re: Smaller than a /24 for BGP?

[William Herrin]

On Sat, Jan 28, 2023 at 11:24 AM William Herrin  wrote:
> QUIC is better, but it still leaves finding the server's new IP
> address as an exercise for a process outside of the protocol.

Gah, brain spat out the wrong info. Bad brain.

QUIC doesn't allow the server to change its IP address; only the
client can change. So it doesn't really help the multihoming
situation.

Regards,
Bill Herrin


-- 
For hire. https://bill.herrin.us/resume/

Re: Smaller than a /24 for BGP?

[William Herrin]

On Sat, Jan 28, 2023 at 10:15 AM Donald Eastlake  wrote:
> Use Multipath TCP
> https://datatracker.ietf.org/group/mptcp/documents/

Doesn't work well. Has security problems (mismatch between reported IP
addresses used and actual addresses in use) and it can't reacquire the
opposing endpoint if an address is lost before a new one is
communicated.

MPTCP has been complete for years. The adoption rate is very low.

QUIC is better, but it still leaves finding the server's new IP
address as an exercise for a process outside of the protocol. I
haven't kept my ear to the ground for the last year or two but I
haven't heard about it making the expected inroads versus HTTP 1.1
over TCP. Unfortunately, QUIC is a very complex protocol that's very
hard to troubleshoot. The complexity comes from a slew of mandatory
security components which should have been optional.

Regards,
Bill Herrin

-- 
For hire. https://bill.herrin.us/resume/

Re: Smaller than a /24 for BGP?

[Donald Eastlake]

Use Multipath TCP
https://datatracker.ietf.org/group/mptcp/documents/

Thanks,
Donald
===
 Donald E. Eastlake 3rd
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Sat, Jan 28, 2023 at 10:07 AM William Herrin  wrote:

> On Fri, Jan 27, 2023 at 9:49 PM Masataka Ohta
>  wrote:
> > That multihomed sites are relying on the entire Internet
> > for computation of the best ways to reach them is not
> > healthy way of multihoming.
>
> This was studied in the IRTF RRG about a decade ago. There aren't any
> other workable ways of multihoming compatible with the TCP protocol,
> not even in theory. Every other mechanism imagined failed some basic
> system constraint, usually the requirement that packets have
> administrative permission to cross an intermediate network. So,
> another way of multihoming critically depends on replacing the layer-4
> protocols with something that doesn't intermingle the IP address with
> the connection identifier.
>
> For clarity: TCP's connection identifier consists of the source and
> destination IP addresses plus the source and destination ports. Those
> four elements, unique when combined, identify exactly one ongoing TCP
> connection. Because of this, the connection must fail if the source or
> destination IP addresses are no longer available to the source or
> destination hosts. From this fact, we get the requirement that the
> entire Internet learn when a particular IP address has changed its
> position within the network.
>
> Regards,
> Bill Herrin
>
>
> --
> For hire. https://bill.herrin.us/resume/
>

Re: Smaller than a /24 for BGP?

[William Herrin]

On Fri, Jan 27, 2023 at 9:49 PM Masataka Ohta
 wrote:
> That multihomed sites are relying on the entire Internet
> for computation of the best ways to reach them is not
> healthy way of multihoming.

This was studied in the IRTF RRG about a decade ago. There aren't any
other workable ways of multihoming compatible with the TCP protocol,
not even in theory. Every other mechanism imagined failed some basic
system constraint, usually the requirement that packets have
administrative permission to cross an intermediate network. So,
another way of multihoming critically depends on replacing the layer-4
protocols with something that doesn't intermingle the IP address with
the connection identifier.

For clarity: TCP's connection identifier consists of the source and
destination IP addresses plus the source and destination ports. Those
four elements, unique when combined, identify exactly one ongoing TCP
connection. Because of this, the connection must fail if the source or
destination IP addresses are no longer available to the source or
destination hosts. From this fact, we get the requirement that the
entire Internet learn when a particular IP address has changed its
position within the network.

Regards,
Bill Herrin


--
For hire. https://bill.herrin.us/resume/

Re: Smaller than a /24 for BGP?

[Masataka Ohta]

Lars Prehn wrote:


Accepting and globally redistributing all hyper-specifics increases
the routing table size by >100K routes (according to what route
collectors see).


That figure is guaranteed minimum but there should be 10 or
100 times more desire for hyper-specifics suppressed by
the established (since early days with class C) practice.

That multihomed sites are relying on the entire Internet
for computation of the best ways to reach them is not
healthy way of multihoming.

Masataka Ohta

Re: Smaller than a /24 for BGP?

[Mike Hammett]

Implementing v6 is important, but unrelated to allowing smaller v4 prefixes. 


Not taking a position either way if smaller v4 prefixes is good or bad. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Chris"  
To: "Justin Wilson (Lists)"  
Cc: nanog@nanog.org 
Sent: Wednesday, January 25, 2023 2:24:29 PM 
Subject: Re: Smaller than a /24 for BGP? 


I would suggest that this is trying to solve the wrong problem. To me this is 
pressure to migrate to v6, not alter routing rules. 


Kind Regards, 
Chris Haun 


On Tue, Jan 24, 2023 at 12:21 PM Justin Wilson (Lists) < li...@mtin.net > 
wrote: 




Have there been talks about the best practices to accept things smaller than a 
/24? I qm seeing more and more scenarios where folks need to participate in BGP 
but they do not need a full /24 of space. Seems wasteful. I know this would 
bloat the routing table immensely. I know of several folks who could split 
their /24 into /25s across a few regions and still have plenty of IP space. 









Justin Wilson 
j...@j2sw.com 

— 
https://blog.j2sw.com - Podcast and Blog https://www.fd-ix.com 

Re: Smaller than a /24 for BGP?

[Jon Lewis]

On Tue, 24 Jan 2023, Forrest Christian (List Account) wrote:


I have two thoughts in relation to this:

1) It's amazing how many threads end up ending in the (correct) summary that 
making an even minor global change to the way the internet works and/or is 
configured to
enable some potentially useful feature isn't likely to happen.

2) I'd really like to be able to tag a BGP announcement with "only use this 
announcement as an absolute last resort" so I don't have to break my prefixes in 
half in
those cases where I have a backup path that needs to only be used as a last 
resort.  (Today each prefix I have to do this with results in 3 prefixes in the 
table where
one would do).

And yes. I know #2 is precluded from actually ever happening because of #1.   
The irony is not lost on me.


With good upstreams (providing useful BGP communities support), you can do 
this without cluttering the global table.


Say you have multiple upstreams, and you want provider A to treat a.b.c/23 
as a "don't use this unless you have no other path" route.  They should 
support a community that allows you to cause them to set localpref lower 
than their "peer default" (or transit if they admit to buying transit). 
Then, when you advertise a.b.c/23 to both/all your providers, provider A 
won't use the direct route unless they're not receiving it from any other 
source.  i.e. You don't have to advertise the /23 to A and a pair of /24s 
to B, C, etc. to make sure A doesn't use the direct customer route.


I don't know that all "tier 1's" support it...but for example, Tata, GTT, 
Cogent, and NTT do:


Tata:
Request for Local Preference Adjustment In AS6453 the default local 
preference (LOCAL_PREF) value for customer-routes is 100, and for 
peer-routes it is 90.  Along the lines of RFC1998, a Tata Communications 
customer may request other than thedefault local preference:

Adjust Local Preference
community   action
6453:n, n={70, 80, 90, 110} assign local preferencen in AS6453

GTT:
3.2.2 Local Preference

 Value   Description
 3257:1980   give routes localpref below normal customer route.
 3257:1970   give routes localpref below normal peer route.


Cogent:
Local Preference
All customer routes announced to Cogent will have a local pref of 130.
The customer can control the local preference for their announcements by 
using a community string that is passed to Cogent in the BGP session. The 
following table lists the community strings and the corresponding local 
preference that will be set when they are used.


Community StringLocal Pref  Effect
174:10  10  Set customer route local preference to 
10
(below everything-least preferred)
174:70  70  Set customer route local preference to 
70
(below peers)
174:120 120 Set customer route local preference to 
120
(below customer default)
174:125 125 Set customer route local preference to 
125
(below customer default)
174:135 135 Set customer route local preference to 
135
(above customer default)
174:140 140 Set customer route local preference to 
140
(above customer default)

You get the idea.  Everyone likely does it "their own way", so you need to 
find the BGP community support info for the upstream with which you want 
non-default behavior / localpref.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Smaller than a /24 for BGP?

[Eric Kuhnke]

> 1) It's amazing how many threads end up ending in the (correct) summary
that making an even minor global change to the way the internet works
and/or is configured to enable some potentially useful feature isn't likely
to happen.

My biggest take-away from this is that software and network engineering
design decisions should be more thoughtful and methodical when setting
address space, number space, name space and size/expandability of whatever
is being configured when designing new things. Even if you think whatever
you've created is inexhaustible for your own purposes. Once something has
been put into widespread use it's extremely difficult to come back and fix
it later.

Such as for ISP internal purposes, like thinking about "okay what if we
take this DNS zone delegation for our internal management network and set
it aside for a vast number of CPEs in the future, hierarchically organized
by where they're going to be installed geographically, for our internal
hostnames and reverse DNS".

I'm sure that the vast global address space of ipv4 looked incredibly large
when put into use as a standard...

Or if you've ever seen an organization that internally set up its
accounting/billing/customer circuit ID system with a namespace/number-space
that didn't scale to meet future needs, or categorization of customers, or
integration of circuit IDs into automation systems.



On Tue, Jan 24, 2023 at 8:13 PM Forrest Christian (List Account) <
li...@packetflux.com> wrote:

> I have two thoughts in relation to this:
>
> 1) It's amazing how many threads end up ending in the (correct) summary
> that making an even minor global change to the way the internet works
> and/or is configured to enable some potentially useful feature isn't likely
> to happen.
>
> 2) I'd really like to be able to tag a BGP announcement with "only use
> this announcement as an absolute last resort" so I don't have to break my
> prefixes in half in those cases where I have a backup path that needs to
> only be used as a last resort.  (Today each prefix I have to do this with
> results in 3 prefixes in the table where one would do).
>
> And yes. I know #2 is precluded from actually ever happening because of
> #1.   The irony is not lost on me.
>
>
> On Tue, Jan 24, 2023, 7:54 PM John Levine  wrote:
>
>> It appears that Chris J. Ruschmann  said:
>> >-=-=-=-=-=-
>> >How do you plan on getting rid of all the filters that don’t accept
>> anything less than a /24?
>> >
>> >In all seriousness If I have these, I’d imagine everyone else does too.
>>
>> Right. Since the Internet has no settlements, there is no way to
>> persuade a network of whom you are not a customer to accept your
>> announcements if they don't want to, and even for the largest
>> networks, that is 99% of the other networks in the world. So no,
>> they're not going to accept your /25 no matter how deeply you believe
>> that they should.
>>
>> I'm kind of surprised that we haven't seen pushback against sloppily
>> disaggregated announcements.  It is my impression that the route table
>> would be appreciably smaller if a few networks combined adjacent a
>> bunch of /24's into larger blocks.
>>
>> R's,
>> John
>>
>

Re: Smaller than a /24 for BGP?

[Chris]

I would suggest that this is trying to solve the wrong problem.  To me this
is pressure to migrate to v6, not alter routing rules.

Kind Regards,
Chris Haun

On Tue, Jan 24, 2023 at 12:21 PM Justin Wilson (Lists) 
wrote:

> Have there been talks about the best practices to accept things smaller
> than a /24? I qm seeing more and more scenarios where folks need to
> participate in BGP but they do not need a full /24 of space.  Seems
> wasteful.  I know this would bloat the routing table immensely.  I know of
> several folks who could split their /24 into /25s across a few regions and
> still have plenty of IP space.
>
>
>
> Justin Wilson
> j...@j2sw.com
>
> —
> https://blog.j2sw.com - Podcast and Blog
> https://www.fd-ix.com
>

Re: Smaller than a /24 for BGP?

[Lars Prehn]

We performed some high-level analyses on these hyper-specific prefixes 
about a year ago and pushed some insights into a blog post [1] and a 
paper [2].


While not many ASes redistribute these prefixes, some accept and use 
them for their internal routing (e.g., NTT's IPv4 filtering policy [3]). 
Rob already pointed out that this is often sufficient for many traffic 
engineering tasks. In the remaining scenarios, announcing a covering /24 
and hyper-specific prefixes may result in some traffic engineering, even 
if the predictability of the routing impact is closer to path prepending 
than usual more-specific announcements. In contrast to John's claim, 
some transit ASes explicitly enabled redistributions of up to /28s for 
their customers upon request (at least, they told us so during interviews).


Accepting and globally redistributing all hyper-specifics increases the 
routing table size by >100K routes (according to what route collectors 
see). There are also about 2-4 de-aggregation events every year in which 
some origin (accidentally) leaks some large number of hyper-specifics to 
its neighbours for a short time.


Best regards,
Lars

[1] 
https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-wild/

[2] https://dl.acm.org/doi/pdf/10.1145/3544912.3544916
[3] https://www.gin.ntt.net/support-center/policies-procedures/routing/


On 25.01.23 05:12, Forrest Christian (List Account) wrote:

I have two thoughts in relation to this:

1) It's amazing how many threads end up ending in the (correct) 
summary that making an even minor global change to the way the 
internet works and/or is configured to enable some potentially useful 
feature isn't likely to happen.


2) I'd really like to be able to tag a BGP announcement with "only use 
this announcement as an absolute last resort" so I don't have to break 
my prefixes in half in those cases where I have a backup path that 
needs to only be used as a last resort.  (Today each prefix I have to 
do this with results in 3 prefixes in the table where one would do).


And yes. I know #2 is precluded from actually ever happening because 
of #1.   The irony is not lost on me.



On Tue, Jan 24, 2023, 7:54 PM John Levine  wrote:

It appears that Chris J. Ruschmann  said:
>-=-=-=-=-=-
>How do you plan on getting rid of all the filters that don’t
accept anything less than a /24?
>
>In all seriousness If I have these, I’d imagine everyone else
does too.

Right. Since the Internet has no settlements, there is no way to
persuade a network of whom you are not a customer to accept your
announcements if they don't want to, and even for the largest
networks, that is 99% of the other networks in the world. So no,
they're not going to accept your /25 no matter how deeply you believe
that they should.

I'm kind of surprised that we haven't seen pushback against sloppily
disaggregated announcements.  It is my impression that the route table
would be appreciably smaller if a few networks combined adjacent a
bunch of /24's into larger blocks.

R's,
John

Re: Smaller than a /24 for BGP?

[Forrest Christian (List Account)]

I have two thoughts in relation to this:

1) It's amazing how many threads end up ending in the (correct) summary
that making an even minor global change to the way the internet works
and/or is configured to enable some potentially useful feature isn't likely
to happen.

2) I'd really like to be able to tag a BGP announcement with "only use this
announcement as an absolute last resort" so I don't have to break my
prefixes in half in those cases where I have a backup path that needs to
only be used as a last resort.  (Today each prefix I have to do this with
results in 3 prefixes in the table where one would do).

And yes. I know #2 is precluded from actually ever happening because of
#1.   The irony is not lost on me.


On Tue, Jan 24, 2023, 7:54 PM John Levine  wrote:

> It appears that Chris J. Ruschmann  said:
> >-=-=-=-=-=-
> >How do you plan on getting rid of all the filters that don’t accept
> anything less than a /24?
> >
> >In all seriousness If I have these, I’d imagine everyone else does too.
>
> Right. Since the Internet has no settlements, there is no way to
> persuade a network of whom you are not a customer to accept your
> announcements if they don't want to, and even for the largest
> networks, that is 99% of the other networks in the world. So no,
> they're not going to accept your /25 no matter how deeply you believe
> that they should.
>
> I'm kind of surprised that we haven't seen pushback against sloppily
> disaggregated announcements.  It is my impression that the route table
> would be appreciably smaller if a few networks combined adjacent a
> bunch of /24's into larger blocks.
>
> R's,
> John
>

Re: Smaller than a /24 for BGP?

[John Levine]

It appears that Chris J. Ruschmann  said:
>-=-=-=-=-=-
>How do you plan on getting rid of all the filters that don’t accept anything 
>less than a /24?
>
>In all seriousness If I have these, I’d imagine everyone else does too.

Right. Since the Internet has no settlements, there is no way to
persuade a network of whom you are not a customer to accept your
announcements if they don't want to, and even for the largest
networks, that is 99% of the other networks in the world. So no,
they're not going to accept your /25 no matter how deeply you believe
that they should.

I'm kind of surprised that we haven't seen pushback against sloppily
disaggregated announcements.  It is my impression that the route table
would be appreciably smaller if a few networks combined adjacent a
bunch of /24's into larger blocks.

R's,
John

Re: Smaller than a /24 for BGP?

[Masataka Ohta]

Jon Lewis wrote:


Yeah, but in another couple years we'll breach the 1M mark and
everybody will have fresh routers with lots of TCAM for a while. If
that were the only issue, it'd be a matter of timing the change well.


Everybody will need them.  Not all will get (or be able to get) them.


Wrong. For /24, direct look up of 16M entry SRAM is enough.
Updating 64K entries for /8 should not be a problem, though
you may also have 64K entry SRAM for /16.

In addition, for small number of local smaller-than-/24
prefixes, another lookup of radix tree by a smaller SRAM
(with 64K entry, we can subdivide 256 /24 into /32)
should be possible.

But, there is no need for costly and power wasting TCAM.

So far, I ignore IPv6, of course.

Masataka Ohta

RE: Smaller than a /24 for BGP?

[Robert McKay]

On 2023-01-25 00:10, Chris J. Ruschmann wrote:

How do you plan on getting rid of all the filters that don’t accept
anything less than a /24?

In all seriousness If I have these, I’d imagine everyone else does
too.


Allow someone to advertise a covering /24 (and route onward to the 
longer prefixes) in exchange for being able to 'research' the traffic?


You do want a cover advertisement, but it will hardly ever be used by 
anyone. It attracts traffic, but before that traffic gets anywhere near 
the origin it hits the more specific longer prefixes and goes straight 
there.. probably via your immediate upstream, which it would have 
anyway.


There are large sections of space that have historically always had 
cover advertisements - 38.0.0.0/8 for instance. If cogent started 
accepting /29's in there they'd work perfectly courtesy of 38/8 - with 
nobody else making any other changes to anything.


Probably before long the other transit ISPs would start accepting the 
longer prefixes too and you'd have fairly functional multi-homing. The 
long tail of other ISPs doesn't even matter since they inevitably hand 
the traffic over to someone who will know what to do with it.


-Rob

RE: Smaller than a /24 for BGP?

[Chris J. Ruschmann]

How do you plan on getting rid of all the filters that don’t accept anything 
less than a /24?

In all seriousness If I have these, I’d imagine everyone else does too.



From: NANOG  On Behalf Of Justin 
Wilson (Lists)
Sent: Tuesday, January 24, 2023 9:19 AM
To: nanog@nanog.org
Subject: Smaller than a /24 for BGP?

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Have there been talks about the best practices to accept things smaller than a 
/24? I qm seeing more and more scenarios where folks need to participate in BGP 
but they do not need a full /24 of space.  Seems wasteful.  I know this would 
bloat the routing table immensely.  I know of several folks who could split 
their /24 into /25s across a few regions and still have plenty of IP space.



Justin Wilson
j...@j2sw.com

—
https://blog.j2sw.com - Podcast and Blog
https://www.fd-ix.com

Re: Smaller than a /24 for BGP?

[Jon Lewis]

On Tue, 24 Jan 2023, William Herrin wrote:


On Tue, Jan 24, 2023 at 11:04 AM Jon Lewis  wrote:

The "other problem" is, every day more gear receiving full routes gets
closer to (or farther past) the point where the resources to hold either
the FIB or RIB just aren't there.  For those using these devices, lowering
the bar and bringing in another 100k or so routes in short order just
isn't an option.


Yeah, but in another couple years we'll breach the 1M mark and
everybody will have fresh routers with lots of TCAM for a while. If
that were the only issue, it'd be a matter of timing the change well.


Everybody will need them.  Not all will get (or be able to get) them.

--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Smaller than a /24 for BGP?

[William Herrin]

On Tue, Jan 24, 2023 at 11:04 AM Jon Lewis  wrote:
> The "other problem" is, every day more gear receiving full routes gets
> closer to (or farther past) the point where the resources to hold either
> the FIB or RIB just aren't there.  For those using these devices, lowering
> the bar and bringing in another 100k or so routes in short order just
> isn't an option.

Yeah, but in another couple years we'll breach the 1M mark and
everybody will have fresh routers with lots of TCAM for a while. If
that were the only issue, it'd be a matter of timing the change well.

Regards,
Bill Herrin


-- 
For hire. https://bill.herrin.us/resume/

Re: Smaller than a /24 for BGP?

[Jon Lewis]

On Tue, 24 Jan 2023, William Herrin wrote:


On Tue, Jan 24, 2023 at 10:19 AM Justin Wilson (Lists)  wrote:

Have there been talks about the best practices to accept things smaller than a 
/24?


Hi Justin,

The short version is: it could happen but it won't. There's no
technical obstacle. It's purely administrative. Tens of thousands of
organizations would have to agree to accept smaller prefixes.That
would only happen if there was something in it for them to start doing
so, something major. And even then it would be a hard lift. There
isn't. Some of those organizations run BGP set up by the last guy, the
current gut doesn't really grok it, and he certainly doesn't subscribe
to any information channels where it's discussed. So it's not going to
happen.


The "other problem" is, every day more gear receiving full routes gets 
closer to (or farther past) the point where the resources to hold either 
the FIB or RIB just aren't there.  For those using these devices, lowering 
the bar and bringing in another 100k or so routes in short order just 
isn't an option.  /24 has been the de facto threshold for routes in the v4 
table long enough that I wouldn't want to be dependent on that changing.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Smaller than a /24 for BGP?

[William Herrin]

On Tue, Jan 24, 2023 at 10:19 AM Justin Wilson (Lists)  wrote:
> Have there been talks about the best practices to accept things smaller than 
> a /24?

Hi Justin,

The short version is: it could happen but it won't. There's no
technical obstacle. It's purely administrative. Tens of thousands of
organizations would have to agree to accept smaller prefixes.That
would only happen if there was something in it for them to start doing
so, something major. And even then it would be a hard lift. There
isn't. Some of those organizations run BGP set up by the last guy, the
current gut doesn't really grok it, and he certainly doesn't subscribe
to any information channels where it's discussed. So it's not going to
happen.

Regards,
Bill Herrin


-- 
For hire. https://bill.herrin.us/resume/

Re: Smaller than a /24 for BGP?

[Ian Chilton]

Hi,

On Tue, 24 Jan 2023, at 6:19 PM, Justin Wilson (Lists) wrote:
> Have there been talks about the best practices to accept things smaller than 
> a /24? I qm seeing more and more scenarios where folks need to participate in 
> BGP but they do not need a full /24 of space. 

Yes, I think one of the reasons this was done was to stop routing table bloat 
by people advertising lots of small more specific routes.

I see your point though - with ipv4 becoming harder and more expensive to 
source, there is maybe a case for allowing people to advertise smaller blocks 
and you could also argue for less wastage where people are advertising /24s 
when they only need a small percentage of those IPs.

The problem now is, regardless of the merits or not of changing that , so many 
routers and so many places (knowledge/experience, guides, books, documents, 
best practices etc) that refer to and advise filtering out prefixes smaller 
than /24, advertising it just wouldn’t be effective if you are trying to 
advertise something and expecting it to be available to all networks.

Look at the take up of IPv6 or RPKI and how long they have been around, pushed, 
recommended etc. Trying to get people to adopt and implement these 
practices/changes is a long process.

Ian