Please note that draft-karstens-pim-multicast-application-ports-01 has been renamed draft-karstens-intarea-multicast-application-port-01
", "time": "2025-03-17T10:04:35Z"}, {"author": "\u00c9ric Vyncke", "text": "Just curious, when there is no mandatory key, are all keys optional ?
", "time": "2025-03-17T10:16:01Z"}, {"author": "Juliusz Chroboczek", "text": "Mic: why is the extended information restricted to errors? I can see it being useful in ICMP reply.
", "time": "2025-03-17T10:20:08Z"}, {"author": "Ron Bonica", "text": "Good idea! support
", "time": "2025-03-17T10:20:11Z"}, {"author": "Juliusz Chroboczek", "text": "Chairs: You need to give the slide clicker control
", "time": "2025-03-17T10:21:40Z"}, {"author": "Dragana Damjanovic", "text": "Proxy and protocol are mandatory keys. If there is no mandatory key, proxy an protocol are mandatory.
", "time": "2025-03-17T10:21:56Z"}, {"author": "\u00c9ric Vyncke", "text": "@dragana, thanks
", "time": "2025-03-17T10:25:06Z"}, {"author": "Carlos Mart\u00ednez", "text": "online is fine
", "time": "2025-03-17T10:26:18Z"}, {"author": "Suresh Krishnan", "text": "@meetecho the room projectors went offline in intarea
", "time": "2025-03-17T10:26:50Z"}, {"author": "Suresh Krishnan", "text": "Boromphimarn 1/2
", "time": "2025-03-17T10:27:20Z"}, {"author": "Lorenzo Miniero", "text": "Notifying the AV team
", "time": "2025-03-17T10:28:00Z"}, {"author": "Juliusz Chroboczek", "text": "This sounds a little bit like the old idea of not using ports in IPv6, but instead having every application run on a different IP.
", "time": "2025-03-17T10:31:14Z"}, {"author": "Carsten Bormann", "text": "audio choppy
", "time": "2025-03-17T10:41:57Z"}, {"author": "Carsten Bormann", "text": "maybe stop video
", "time": "2025-03-17T10:42:00Z"}, {"author": "Tommy Jensen", "text": "@Juliusz: RFC 9663 has entered the chat
", "time": "2025-03-17T10:42:41Z"}, {"author": "David Lamparter", "text": "it's getting worse it seems
", "time": "2025-03-17T10:43:09Z"}, {"author": "David Schinazi", "text": "Sorry Juliusz we had a very hard time understanding you in the room
", "time": "2025-03-17T10:43:22Z"}, {"author": "Nathan Karstens", "text": "@Juliusz it is somewhat similar. By reserving a specific port we still can use UDP and all of the existing socket APIs, no platforms need to change for this to be used, but there are some changes that would be beneficial.
", "time": "2025-03-17T10:43:47Z"}, {"author": "Tommy Jensen", "text": "I'm one of the people Warren is talking about. Tobias demoed this 5549 functionality one day and blew my mind.
", "time": "2025-03-17T10:45:32Z"}, {"author": "David Lamparter", "text": "these slides are 'mildly' understating the deployment of this stuff in datacenters in BGP setups ;D
", "time": "2025-03-17T10:47:29Z"}, {"author": "Juliusz Chroboczek", "text": "It was perfect, thanks a lot Warren.
", "time": "2025-03-17T10:48:44Z"}, {"author": "David Schinazi", "text": "Your mic is live Juliusz
", "time": "2025-03-17T10:49:00Z"}, {"author": "David Schinazi", "text": "(heard what was either typing or perhaps Morse code)
", "time": "2025-03-17T10:49:21Z"}, {"author": "Carlos Mart\u00ednez", "text": "Support !!
", "time": "2025-03-17T10:50:25Z"}, {"author": "Juliusz Chroboczek", "text": "David Lamparter, I wasn't aware of that.
", "time": "2025-03-17T10:51:05Z"}, {"author": "Carlos Mart\u00ednez", "text": "The RIRs critical infrastructure pools are getting depleted as we speak.
\nThinks like new IXPs will badly need this.
", "time": "2025-03-17T10:51:29Z"}, {"author": "David Lamparter", "text": "@Juliusz aware of which 'that'?
", "time": "2025-03-17T10:51:30Z"}, {"author": "Carlos Mart\u00ednez", "text": "Things*
", "time": "2025-03-17T10:51:50Z"}, {"author": "Joel Halpern", "text": "This should be compatible with savnet.
", "time": "2025-03-17T10:51:53Z"}, {"author": "Juliusz Chroboczek", "text": "Aware that the technique is actually deployed in datacenters. We'll try to fix the stress in the next revision, hopefully with your help.
", "time": "2025-03-17T10:51:59Z"}, {"author": "Carsten Bormann", "text": "BCP, actually
", "time": "2025-03-17T10:53:31Z"}, {"author": "Carlos Mart\u00ednez", "text": "+1 for BCP
", "time": "2025-03-17T10:53:52Z"}, {"author": "\u00c9ric Vyncke", "text": "BCP would be good as well
", "time": "2025-03-17T10:54:05Z"}, {"author": "Juliusz Chroboczek", "text": "The point is that we need something that can be cited normativaly in Standards Track protocol RFCs, so I guess BCP fits the bill.
", "time": "2025-03-17T10:54:30Z"}, {"author": "Juliusz Chroboczek", "text": "(Not sure.)
", "time": "2025-03-17T10:54:47Z"}, {"author": "David Lamparter", "text": "Ah. I might be able to get numbers, but also there is a very specific reason this is used in datacenter setups: IPv6 linklocals allow fully automatic BGP setups, removing the need for link-specific / peer-specific config. (Even just your own IPv4 address on a link.)
", "time": "2025-03-17T10:55:05Z"}, {"author": "Juliusz Chroboczek", "text": "David, something we could use as an informative reference would be useful.
", "time": "2025-03-17T10:56:04Z"}, {"author": "David Lamparter", "text": "I'm not sure the \"automatic\" part of it was ever written down anywhere; the mechanisms slightly differ between vendors.
", "time": "2025-03-17T10:56:42Z"}, {"author": "David Lamparter", "text": "But not needing per-link IPv4 addresses is just a \"basic fact\" even without making it automatic
", "time": "2025-03-17T10:57:11Z"}, {"author": "David Lamparter", "text": "or rather
", "time": "2025-03-17T10:57:51Z"}, {"author": "\u00c9ric Vyncke", "text": "and a useful thing
", "time": "2025-03-17T10:57:58Z"}, {"author": "Carsten Bormann", "text": "We don't have a category \"toolbox\", we really should have
", "time": "2025-03-17T10:58:07Z"}, {"author": "\u00c9ric Vyncke", "text": "(notably for RIB size)
", "time": "2025-03-17T10:58:10Z"}, {"author": "David Lamparter", "text": "I mean, it's just a corollary from your presentation, not needing IPv4 also means not configuring IPv4
", "time": "2025-03-17T10:58:19Z"}, {"author": "Carsten Bormann", "text": "(as in \"becomes normative when cited as normative\")
", "time": "2025-03-17T10:58:41Z"}, {"author": "Antoine Fressancourt", "text": "I still fail to see how a different ether type rendr
", "time": "2025-03-17T10:59:10Z"}, {"author": "Antoine Fressancourt", "text": "Renders safer limited domains to be honest
", "time": "2025-03-17T10:59:33Z"}, {"author": "Suresh Krishnan", "text": "@Antoine, there are some operators who wanted limited domain protocols to be explicitly enabled in their network interfaces
", "time": "2025-03-17T11:00:34Z"}, {"author": "Joel Halpern", "text": "@Antoine - if your external interfaces do not accept that Eterhetype, you get fail-closed behavvior.
", "time": "2025-03-17T11:00:45Z"}, {"author": "Antoine Fressancourt", "text": "Thanks for clarifying
", "time": "2025-03-17T11:03:44Z"}, {"author": "Juliusz Chroboczek", "text": "We're always coming to the same conclusion: allowing ICMP to be originated from intermediate routers causes brittleness.
\nECN, with its funky feedback mechanism, shows how that could have been avoided.
how is this not just an amplification attack vector?
", "time": "2025-03-17T11:12:20Z"}, {"author": "Erik Kline", "text": "and also a state exhaustion attack
", "time": "2025-03-17T11:14:55Z"}, {"author": "Tommy Jensen", "text": "+1 Erik and \u00c9ric
", "time": "2025-03-17T11:17:46Z"}, {"author": "Chris Box", "text": "I was very glad to see Ingemar raise this topic, because we suffered the performance impact of 3GPP resequencing last year. We have traces where it ended up causing ACKs to be held up for a few hundred milliseconds. Agree that guidance needs revising for modern networks and latency targets.
", "time": "2025-03-17T11:22:44Z"}, {"author": "Chris Box", "text": "Also Gorry may remember me asking him about this previously!
", "time": "2025-03-17T11:24:27Z"}, {"author": "Ingemar Johansson", "text": "Thanks. Yes, I think IETF can really help to provide with guidance to 3GPP implementors and other SDOs here
", "time": "2025-03-17T11:24:40Z"}, {"author": "Juliusz Chroboczek", "text": "SDO?
", "time": "2025-03-17T11:24:51Z"}, {"author": "Suresh Krishnan", "text": "Standards Development Organizations
", "time": "2025-03-17T11:25:22Z"}, {"author": "Joel Halpern", "text": "It seems clear that saying some disordering can be tolerated is factual. But, it seems that trying to providing any meaningful guidelines as to degree seems to fall to other WGs, including IPSEC, TCPM, and QUIC.
", "time": "2025-03-17T11:25:27Z"}, {"author": "Juliusz Chroboczek", "text": "ty
", "time": "2025-03-17T11:25:27Z"}, {"author": "Carsten Bormann", "text": "The point here is that there is a direction in which the Internet goes:
", "time": "2025-03-17T11:27:26Z"}, {"author": "Suresh Krishnan", "text": "Closing the queue as we will run out of time
", "time": "2025-03-17T11:27:49Z"}, {"author": "Carsten Bormann", "text": "Tolerating more reordering, and being less frightened about creating some reordering.
", "time": "2025-03-17T11:27:51Z"}, {"author": "Joel Halpern", "text": "@Carsten - yes. Just unclear how we work on making it clear.
", "time": "2025-03-17T11:28:16Z"}, {"author": "Juliusz Chroboczek", "text": "On WiFi, you get massive reordering if you use both unicast and multicast in the same protocol, which caused us massive trouble in Babel. RFC 9467 is just part of the story.
", "time": "2025-03-17T11:29:06Z"}, {"author": "\u00c9ric Vyncke", "text": "As it appears like a research topic, I wonder whether it is a work to be done at IETF or IRTF
", "time": "2025-03-17T11:31:23Z"}, {"author": "Carsten Bormann", "text": "IRTF actually makes sense...
", "time": "2025-03-17T11:32:02Z"}, {"author": "Carsten Bormann", "text": "(Or IAB!)
", "time": "2025-03-17T11:32:51Z"}]