@Jen Linkova I updated the slides again to change all instances of \"stub router\" to \"SNAC router\".
", "time": "2024-03-21T03:24:54Z"}, {"author": "Ted Lemon", "text": "@Jen Linkova I updated the slides again to change all instances of \"stub router\" to \"SNAC router\".
", "time": "2024-03-21T03:25:23Z"}, {"author": "Bob Hinden", "text": "I approved the slides, will see if meetecho updates in time.
", "time": "2024-03-21T03:26:54Z"}, {"author": "Ted Lemon", "text": "Thanks!
", "time": "2024-03-21T03:27:01Z"}, {"author": "Mohamed Boucadair", "text": "Ketan has a point. This is exactly why I asked to remove it from the EH
", "time": "2024-03-21T03:27:33Z"}, {"author": "Mohamed Boucadair", "text": "we won't have 100 NRPs
", "time": "2024-03-21T03:28:23Z"}, {"author": "Mohamed Boucadair", "text": "I'm not even sure there will be more than 1 to put it politely.
", "time": "2024-03-21T03:28:47Z"}, {"author": "Ketan Talaulikar", "text": "@Med yes a few/handful is what I've heard as well
", "time": "2024-03-21T03:30:08Z"}, {"author": "Ketan Talaulikar", "text": "But I am not precluding more. My point was about simplicity and h/w pipeline efficiency
", "time": "2024-03-21T03:30:39Z"}, {"author": "Mohamed Boucadair", "text": "The number is important here as this will have implication on the configuration burden mentioned by Jie
", "time": "2024-03-21T03:31:41Z"}, {"author": "Ketan Talaulikar", "text": "Yes, number is also important. But again, that is a topic for TEAS WG. I will start and email thread on this later today.
", "time": "2024-03-21T03:35:35Z"}, {"author": "Jie Dong", "text": "It is OK to take the discussion about NRP number to TEAS.
", "time": "2024-03-21T03:36:07Z"}, {"author": "Mohamed Boucadair", "text": "I'm not sure we will get an answer, but please do. Thanks
", "time": "2024-03-21T03:36:31Z"}, {"author": "Jie Dong", "text": "As for the encoding, using flag to control the forwarding behavior of specific packets is already used in the design of IPv6 extension headers. Devices support extension header should be capable of that processing.
", "time": "2024-03-21T03:39:38Z"}, {"author": "Michael Richardson", "text": "O(1) state in router for 2^64 downstream devices.
", "time": "2024-03-21T03:41:47Z"}, {"author": "Jie Dong", "text": "Another thing to consider is extensibility, we have had that discussion in previous IETF meetings, and it seems people want to see this option/ID being generic and to be used for other applications (in addition to identifying the forwarding resources)
", "time": "2024-03-21T03:41:48Z"}, {"author": "Greg Mirsky", "text": "@Jie, I apologize for not following the discussion today. One argument caught my eye. Please help me understand, that you envision that OAM test packets might be arbitrary dropped. Is that the case? Would that cause fault negative alarms?
", "time": "2024-03-21T03:46:18Z"}, {"author": "Jie Dong", "text": "@Michael Richardson right, and the classification rules to be deployed on every node needs to be very flexible (complex) in this case
", "time": "2024-03-21T03:46:31Z"}, {"author": "Greg Mirsky", "text": "s/fault/false/ ;)
", "time": "2024-03-21T03:47:42Z"}, {"author": "Jie Dong", "text": "@Greg Mirsky What I said was OAM packets used to check the availability of an NRP should be dropped when there is no NRP provisioned on a transit node, this way it can correctly reflect the status of the NRP
", "time": "2024-03-21T03:48:16Z"}, {"author": "Greg Mirsky", "text": "@Jie,
", "time": "2024-03-21T03:48:44Z"}, {"author": "Greg Mirsky", "text": "but the purpose and the expectation of a function that sent the query is to receive response. Not?
", "time": "2024-03-21T03:49:24Z"}, {"author": "Greg Mirsky", "text": "If the request merely times out, how it can be distinguished from the network defect?
", "time": "2024-03-21T03:50:11Z"}, {"author": "Michael Richardson", "text": "my Thanks to Brian for continuing to persue this. This looks like a good way to avoid further useless holes in the ground.
", "time": "2024-03-21T03:50:52Z"}, {"author": "Jie Dong", "text": "@Greg Mirsky If the purpose of the OAM packet is to check the connectivity (say BFD), not receiving the packet would be the expected result to detect the failure of an NRP
", "time": "2024-03-21T03:51:41Z"}, {"author": "Greg Mirsky", "text": "BFD is not intended to check availability of an application but only the forwarding path and the forwarding engine (to a certain degree). Frankly, I'm now more confused by the idea behind that mechanism than before.
", "time": "2024-03-21T03:53:18Z"}, {"author": "Greg Mirsky", "text": "In MPLS, LSP Ping can be used to check the consistency between the control and data plane. AFAIK, there's seems no analogous functionality in IPv6 yet.
", "time": "2024-03-21T03:54:56Z"}, {"author": "Jie Dong", "text": "@Greg Mirsky we can discuss about OAM after the meeting, but the S flag is not only for the OAM packets, it can be set on demand for specific flows of packets according to the policy on \"drop or fallback\"
", "time": "2024-03-21T03:56:37Z"}, {"author": "Greg Mirsky", "text": "@Jie, sure, let continue the discussion. Though, I'd like to make a point that IMHO the applicability of S flag to OAM must be made clear before the document moves forward.
", "time": "2024-03-21T03:58:37Z"}, {"author": "Michael Richardson", "text": "@Lorenzo Colitti how can we get a default zone/scope implemented for Linux Kernel.
", "time": "2024-03-21T03:59:03Z"}, {"author": "Michael Richardson", "text": "could it be per-process.... inherited to child processes.
", "time": "2024-03-21T03:59:35Z"}, {"author": "Michael Richardson", "text": "% set-default-scope 14; chrome &
", "time": "2024-03-21T03:59:59Z"}, {"author": "Jie Dong", "text": "@Greg Mirsky Currently there is no mentioning/restriction about the setting of the S flag on packets. All depends on operators policy.
", "time": "2024-03-21T04:03:26Z"}, {"author": "Greg Mirsky", "text": "@Jie, I believe that the case of OAM must be explicitly discussed or it is excluded from the S-flag altogether. I strongly believe that playing with arbitrary policies toward OAM is a clear path to a problem that would be hard to detect and troubleshoot, as you may have turned off the very mechanism that is intended to help you in the detection and localization of the problem.
", "time": "2024-03-21T04:08:11Z"}, {"author": "Jie Dong", "text": "@Greg Mirsky thanks for your suggestion, we will take it into consideration
", "time": "2024-03-21T04:09:47Z"}, {"author": "Tommy Jensen", "text": "Love the transcription
", "time": "2024-03-21T04:13:06Z"}, {"author": "\u00c9ric Vyncke", "text": "As individual: let's have SNAC routers sending M&O flags to 0
", "time": "2024-03-21T04:17:49Z"}, {"author": "Timothy Winters", "text": "@Eric, that might work Can we think if any host on a SNAC router might be triggered by the flags?
", "time": "2024-03-21T04:19:32Z"}, {"author": "\u00c9ric Vyncke", "text": "Unsure whether a SNAC router should also have a pure host function (or can simply start stateful/stateless DHCP anyway)
", "time": "2024-03-21T04:22:01Z"}, {"author": "Timothy Winters", "text": "Sorry I meant a SNAC router sending RAs to a host attached to it.
", "time": "2024-03-21T04:23:05Z"}, {"author": "\u00c9ric Vyncke", "text": "on the stub network then? Good question
", "time": "2024-03-21T04:23:34Z"}, {"author": "Toerless Eckert", "text": "ENOQUEUE for truce ?
", "time": "2024-03-21T04:23:52Z"}, {"author": "Toerless Eckert", "text": "Just wondering if there would need to be some exponential backup requirement to avoid lots of MUST triggered messages in case of problems. Or rate-limit, or any of our common texts for such cases
", "time": "2024-03-21T04:24:42Z"}, {"author": "Michael Richardson", "text": "I want 6man to adopt this, because I think that we can make it slightly better than the storey with NAT44.
", "time": "2024-03-21T04:46:13Z"}, {"author": "Michael Richardson", "text": "+1 on everything Lorenzo said.
", "time": "2024-03-21T04:48:08Z"}, {"author": "Nick Buraglio", "text": "As one of the co-authors of this update, I am happy to respond to these
", "time": "2024-03-21T04:48:36Z"}, {"author": "Fernando Gont", "text": "Full disclosure: I haven't read the draft. But i would note that NAT-PT for v6 is how IPv6 is used in Kubernets (including Google Cloud Platform). wishes does not necessarily match reality.
", "time": "2024-03-21T04:49:00Z"}, {"author": "Michael Richardson", "text": "Fernando Gont said:
\n\n\nFull disclosure: I haven't read the draft. But i would note that NAT-PT for v6 is how IPv6 is used in Kubernets (including Google Cloud Platform). wishes does not necessarily match reality.
\n
Really? I thought they did DHCPv6-PD.
", "time": "2024-03-21T04:49:27Z"}, {"author": "Fernando Gont", "text": "Nope. They essentially mimicked ipV4 FOR THE ipv6 case. Train has left.
", "time": "2024-03-21T04:49:54Z"}, {"author": "Fernando Gont", "text": "(I'm referring to Kubernetes, not regular compute instances)
", "time": "2024-03-21T04:50:21Z"}, {"author": "Michael Richardson", "text": "Fernando Gont said:
\n\n\nNope. They essentially mimicked ipV4 FOR THE ipv6 case. Train has left.
\n
I disagree: the engine has left the station, the caboose is still visible :-)
", "time": "2024-03-21T04:50:35Z"}, {"author": "Tom Hill", "text": "Minimal uses, and will definitely be over utilised. \"Because it looks the same as NAT44\"
", "time": "2024-03-21T04:50:53Z"}, {"author": "Lorenzo Colitti", "text": "it was experimental because there was no cosensus on anything else
", "time": "2024-03-21T04:50:58Z"}, {"author": "Ted Lemon", "text": "TWO votes for historic!
", "time": "2024-03-21T04:51:08Z"}, {"author": "Fernando Gont", "text": "It's pretty much production. That's what we use in production clusters in gcp nowadays.
", "time": "2024-03-21T04:51:41Z"}, {"author": "Michael Richardson", "text": "Yeah, Toerless, we have Industrial examples of anti-patterns for NAT44: How it leads to major insecurity.
", "time": "2024-03-21T04:51:55Z"}, {"author": "Ted Lemon", "text": "@Toerless Eckert in the industrial cast you should just use ULA. Industrial settings SHOULD NOT be using the global internet.
", "time": "2024-03-21T04:52:15Z"}, {"author": "Erik Kline", "text": "do we have a description of the \"industrial use case\" somewhere?
", "time": "2024-03-21T04:52:30Z"}, {"author": "Fernando Gont", "text": "+1 to ted
", "time": "2024-03-21T04:52:50Z"}, {"author": "Erik Kline", "text": "I was thinking was Ted said, but...
", "time": "2024-03-21T04:52:53Z"}, {"author": "Nick Buraglio", "text": "I have some that we use for scientific instruments that functionally fall into that category
", "time": "2024-03-21T04:52:58Z"}, {"author": "Ted Lemon", "text": ":)
", "time": "2024-03-21T04:52:59Z"}, {"author": "Michael Richardson", "text": "Ted Lemon said:
\n\n\nToerless Eckert in the industrial cast you should just use ULA. Industrial settings SHOULD NOT be using the global internet.
\n
Nope, ULA does not work. NAT44 leads to lack of ability to audit. They want to move towards a flat network with sdn managed L2 firewalls.
", "time": "2024-03-21T04:53:16Z"}, {"author": "Lorenzo Colitti", "text": "the kubernetes ship has not necessarily sailed. it's software, it can be fixed if something better (PD?) comes along
", "time": "2024-03-21T04:53:37Z"}, {"author": "Michael Richardson", "text": "Lorenzo Colitti said:
\n\n\nthe kubernetes ship has not necessarily sailed. it's software, it can be fixed if something better (PD?) comes along
\n
Docker has PD, AFAIK, but on Amazon, it can't be used for stupid reasons.
", "time": "2024-03-21T04:54:11Z"}, {"author": "Ted Lemon", "text": "@Michael Richardson I have no idea what you mean by this. You don't need NAT at all with ULA. If you need to connect networks together, you connect them together. There's no need for address rewrites or global addresses.
", "time": "2024-03-21T04:54:20Z"}, {"author": "Ted Lemon", "text": "If you really really want global addresses, you can buy a block from an RIR, but why on earth would you ever route a factory floor to the global internet? This is a recipe for ransomware attacks.
", "time": "2024-03-21T04:55:16Z"}, {"author": "Nick Buraglio", "text": "ULA works well for contained sensor networks. If they need external connectivity they can use an application proxy or GUA
", "time": "2024-03-21T04:55:36Z"}, {"author": "Michael Richardson", "text": "Ted Lemon said:
\n\n\nMichael Richardson I have no idea what you mean by this. You don't need NAT at all with ULA. If you need to connect networks together, you connect them together. There's no need for address rewrites or global addresses.
\n
The lack of a \"PD\" in IPv4 leads to multiple layers of NAT44 for industrial networks, which means that they auditing system can not see all the devices/traffic. ULA with routing of ULA subnets would work, but at that point, one can just use PI GUA and a simple outgoing-only firewall.
", "time": "2024-03-21T04:55:49Z"}, {"author": "Fernando Gont", "text": "In theory, you qould be able to make Kubernetes work with unique addresses. In practice, for the most part you wouldn't care to do so.
", "time": "2024-03-21T04:56:12Z"}, {"author": "Michael Richardson", "text": "(many sins are hidden by NAT44)
", "time": "2024-03-21T04:56:13Z"}, {"author": "Ted Lemon", "text": "Sure, but why would you do that. Why do you want outgoing connectivity?
", "time": "2024-03-21T04:56:19Z"}, {"author": "Michael Richardson", "text": "I've been experiencing a lot of issues with NAT. With IPv6, I don't think it should be repeated.
", "time": "2024-03-21T04:57:35Z"}, {"author": "\u00c9ric Vyncke", "text": "Let's face it: everyone hates NAT (and many of us ULA). Having said this, should the IETF be pragmatic and try to \"herd\" NAT66 implementations ? Endless discussions of course
", "time": "2024-03-21T04:58:06Z"}, {"author": "Ted Lemon", "text": "Hm. Our preference is to host software updates locally. I think this is sort of what SUIT is working on, isn't it?
", "time": "2024-03-21T04:58:07Z"}, {"author": "Lorenzo Colitti", "text": "I think that instead of herding NAT66 implementations we can better spend our time providing better solutions to the problems that people try to solve with NAT66
", "time": "2024-03-21T04:59:12Z"}, {"author": "Tommy Jensen", "text": "\n\nLet's face it: everyone hates NAT (and many of us ULA). Having said this, should the IETF be pragmatic and try to \"herd\" NAT66 implementations ?
\n
I worry that this pragmatism will undermine our other work as then questions will arise about why newer RFCs don't work well with this one (and the informational/PS nuance will be lost on customers)
", "time": "2024-03-21T04:59:18Z"}, {"author": "Michael Richardson", "text": "\u00c9ric Vyncke said:
\n\n\nLet's face it: everyone hates NAT (and many of us ULA). Having said this, should the IETF be pragmatic and try to \"herd\" NAT66 implementations ? Endless discussions of course
\n
We should adopt and publish NPTv6, because we treated NAT44 the way oppressive regimes treated AIDS: as a sign you were a deviant. So it spread, unchecked.
", "time": "2024-03-21T04:59:38Z"}, {"author": "\u00c9ric Vyncke", "text": "@lorenzo no disagreement on working of usable solutions
", "time": "2024-03-21T04:59:40Z"}, {"author": "Michael Richardson", "text": "Lorenzo Colitti said:
\n\n\nI think that instead of herding NAT66 implementations we can better spend our time providing better solutions to the problems that people try to solve with NAT66
\n
Yes. I want that too.
", "time": "2024-03-21T04:59:59Z"}, {"author": "Ted Lemon", "text": "I would also very specifically like it to be the case that an IETF standards-track document that tries to reference NPTv6 would be a down-reference and would get special attention and perhaps opprobrium.
", "time": "2024-03-21T05:00:09Z"}, {"author": "Tommy Jensen", "text": "\n\nwe treated NAT44 the way oppressive regimes treated AIDS: as a sign you were a deviant. So it spread, unchecked.
\n
One diff: NAT had to spread due to address exhaustion. Fortunately, we still have a few IPv6 addresses left.
", "time": "2024-03-21T05:00:35Z"}, {"author": "Ted Lemon", "text": "One or two.
", "time": "2024-03-21T05:00:46Z"}, {"author": "Lorenzo Colitti", "text": "+100
", "time": "2024-03-21T05:00:47Z"}, {"author": "Naoki Matsuhira", "text": "Thank you on agenda.
", "time": "2024-03-21T05:01:09Z"}, {"author": "Michael Richardson", "text": "Tommy Jensen said:
\n\n\n\n\nwe treated NAT44 the way oppressive regimes treated AIDS: as a sign you were a deviant. So it spread, unchecked.
\nOne diff: NAT had to spread due to address exhaustion. Fortunately, we still have a few IPv6 addresses left.
\n
Not at the beginning. Not when the various protocols and socializations were developing. Addresses were available, but they were not free, often way over-priced.
", "time": "2024-03-21T05:01:38Z"}]