Re: Suppliers of Optics, Cables, and Parts and Support in Argentina

[nanoguser99 via NANOG]

Robert,

Thank you.  Perhaps ChatGPT can help me post in Spanish, it could not help me 
locate the suppliers :).

- Nanoguser99



--- Original Message ---
On Wednesday, January 25th, 2023 at 9:13 PM, Robert Story  
wrote:


> On Wed 2023-01-25 21:02:09+ nanoguser99 wrote:
> 
> > South America is a difficult region to procure parts in but Argentina
> > is particularly difficult. Our current process is to ship spare gear
> > to Argentina but we get hit very hard with import duties. I'm looking
> > for a local supplier of Optics, Cables, and Parts (drives, RAM, etc.)
> > locally in Argentina.
> > [...]
> 
> 
> You might try posting to the LACNOG list. In Spanish if you can, but
> there are occasional posts in English too..
> 
> lac...@lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> 
> Regards,
> Robert
> 
> --
> Robert Story
> USC Information Sciences Institute http://www.isi.edu/
> 
> Networking and Cybersecurity Division

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: Suppliers of Optics, Cables, and Parts and Support in Argentina

[Robert Story]

On Wed 2023-01-25 21:02:09+ nanoguser99 wrote:
> South America is a difficult region to procure parts in but Argentina
> is particularly difficult.  Our current process is to ship spare gear
> to Argentina but we get hit very hard with import duties. I'm looking
> for a local supplier of Optics, Cables, and Parts (drives, RAM, etc.)
> locally in Argentina.
> [...]

You might try posting to the LACNOG list. In Spanish if you can, but
there are occasional posts in English too..

lac...@lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog

Regards,
Robert

--
Robert Story 
USC Information Sciences Institute 
Networking and Cybersecurity Division

Suppliers of Optics, Cables, and Parts and Support in Argentina

[nanoguser99 via NANOG]

Nanog,

Our organization is US based.

South America is a difficult region to procure parts in but Argentina is 
particularly difficult.  Our current process is to ship spare gear to Argentina 
but we get hit very hard with import duties. I'm looking for a local supplier 
of Optics, Cables, and Parts (drives, RAM, etc.) locally in Argentina.

As a second initiative we are exploring putting a few systems under a support 
contract so we don't deal with the headache that comes with navigating 
importing gear there.  We would be putting a few generic supermicro servers 
(CPU, RAM, Motherboard, disk) and some network equipment (Cisco\Juniper) under 
support.

Any help from anyone who has navigated this would be appreciated.

-Nanoguser99

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