Le Wed, Nov 24, 2021 at 05:08:43PM -0800, William Herrin a écrit :
> I don't recall there being any equipment or software compatibility
> concerns with 1.0.0.0/8. If you do, feel free to refresh my memory.
Perhaps not the whole /8 but definitely some buggy implementations :
Baldur Norddahl wrote:
Are you proposing SCTP? There is sadly not much more hope for widespread
adoption of that as of IPv6.
My ID describes the architectural framework both for IPv4 and IPv6.
Modification to TCP is discussed, for example, in:
On Wed, Nov 24, 2021 at 4:36 PM David Conrad wrote:
>> I like research but what would the RIRs study? The percentage of the
>
> Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC
> and they said similar things when 1.1.1.0/24 was stood up as an
> experiment by Cloudflare and
Anecdotally, anyone that's had reason to manually go through logs for port
5060 SIP for any public facing ipv4 /32 will see the vast amounts of random
"things" out there on the internet trying common extension password combos
to register.
It's been a large amount of background noise on the
Bill,
On Nov 23, 2021, at 11:12 PM, William Herrin wrote:
>> 1. IAB or IESG requests the IANA team to delegate one of
>> the 240/4 /8s to the RIRs on demand for experimental
>> purposes for a fixed period of time (a year or two?).
>
> I like research but what would the RIRs study? The
On Wed, Nov 24, 2021 at 5:12 PM Geoff Huston wrote:
>
>
> > On 25 Nov 2021, at 7:57 am, Christopher Morrow
> wrote:
> >
> > Are you proposing SCTP? There is sadly not much more hope for widespread
> adoption of that as of IPv6.
> >
> > or perhaps MP-TCP? :) or shim6?
>
> Shim6 died a
> On 25 Nov 2021, at 7:57 am, Christopher Morrow
> wrote:
>
> Are you proposing SCTP? There is sadly not much more hope for widespread
> adoption of that as of IPv6.
>
> or perhaps MP-TCP? :) or shim6?
Shim6 died a comprehensive death many yers ago. I recall NANOG played a role in
it's
Hi all,
I hope you don't mind the post, but thought this might be of use and
in the spirit of release early, release often I've done an alpha
release:
https://github.com/SentryPeer/SentryPeer
There's a presentation too if you'd like to watch/read where I hope to
go with this:
On Wed, Nov 24, 2021 at 9:12 AM Baldur Norddahl
wrote:
>
>
> On Wed, 24 Nov 2021 at 08:16, Masataka Ohta <
> mo...@necom830.hpcl.titech.ac.jp> wrote:
>
>> So, as modifying end systems is inevitable, there is
>> no reason not to support full end to end multihoming
>> including modifications to
We are receiving latency complaints to Salesforce, anyone else seeing this?
Looks like Vocus Network might be possibly leaking some force.com (Salesforce)
routes, causing 200ms of latency. Traffic is going Chicago -> Vocus Networks ->
Australia -> Akamai Atlanta
I have emailed both Vocus
Ha, my apologies, I thought I was writing this for a Linux User Group, not
a NOG. Ignore my simplistic explanations.
- Thomas Scott | mr.thomas.sc...@gmail.com
On Wed, Nov 24, 2021 at 12:47 PM Thomas Scott
wrote:
> I have used it successfully in a test environment that I was using ECMP
> in.
I have used it successfully in a test environment that I was using ECMP in.
Most of the public networks that I've worked with don't use ECMP as often
as other methods for steering traffic (LAGs, BGP MEDs, etc).
What I have seen it fantastically useful for was troubleshooting a transit
provider,
The tool fbtracert (http://github.com/facebookarchive/fbtracert) was mentioned
here recently as a way to get visibility into multi-pathing.
Has anyone here ever used this tool successfully?
Supposedly Facebook uses this tool internally, but… that doesn’t help much.
I’ve tried it on 4 different
On Wed, 24 Nov 2021 at 16:16, Baldur Norddahl wrote:
> Are you proposing SCTP? There is sadly not much more hope for widespread
> adoption of that as of IPv6.
If you use Apple, you use MP-TCP, for better UX while using both
mobile and wifi.
SCTP is no good, because you cannot transition
On Wed, 24 Nov 2021 at 08:16, Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> So, as modifying end systems is inevitable, there is
> no reason not to support full end to end multihoming
> including modifications to support multiple addresses
> by TCP and some applications.
>
>
15 matches
Mail list logo
