On 24-Mar-21 10:27, Mark Smith wrote: > > > On Wed, 24 Mar 2021, 07:53 Vasilenko Eduard, <[email protected] > <mailto:[email protected]>> wrote: > > Hi Joseph,____ > > __ __ > > Currently, vendors have chosen some undisclosed big numbers for the > reassembly buffer on the tunnel interface____ > > Or no buffer at all for tunnels that do not support reassembly.____ > > That does not create any additional restriction for MTU.____ > > Nobody did believe (IPv4 or IPv6 – does not matter) that buffer > requirements for end nodes are applicable for transit nodes. > > > I don't think you're not fully understanding the difference between hosts and > routers. I'm guessing you're thinking and imagining them as physical devices. > The definitions are actually functional (and the dictionary definition of the > word "device" is not a physical device.) > > Outer tunnel packet header DAs are obviously the tunnel end-point IP > addresses. > > Which of these definitions from RFC 8200 describes what type of IPv6 node a > tunnel end point is? > > " router a node that forwards IPv6 packets not explicitly > addressed to itself. > > host any node that is not a router." > > Tunnel packets *are* explicitly addressed to a node, so tunnel endpoints are > performing host functions on packets. If those host functions being performed > on tunnel packets at the tunnel endpoints require buffers, then buffers need > to be available.
Yes, and tunnel entry points are hosts when they send an encapsulated packet. There's a subtlety though, which is that the device that contains the tunnel entry point on the downstream side of the packet flow is indeed a router on the upstream side. Conversely, the device that contains the tunnel exit point is a host on the upstream side and a router on the downstream side. Which is why the MTU for packets inside the tunnel is no business of anyone upstream or downstream of the tunnel. Brian > > Internally, a router as a device (your "transit node") is performing both > host and routing functions. The forwarding plane component is: > > "a node that forwards IPv6 packets not explicitly addressed to itself" - a > router > > The control plane, and other functions like tunnel endpoints, in a router as > a device, is: > > "any node that is not a router" - a host > > This is the same for IPv4: > > RFC791, > > "The internet protocol provides for transmitting blocks of data called > datagrams from sources to destinations, where sources and destinations are > *hosts* identified by fixed length addresses." > > (And as another example of device verses function. If you buy a router as a > device from a router vendor (rack mount, multiple interfaces, limited LCD/LED > display, console port), and then use it as a BGP Route Reflector, such that > it never forwards packets because it is never in a forwarding path, is it > still a "router"? It might look like one, but it is only performing host > packet processing of the BGP protocol.) > > > ____ > > Your liberty to apply the requirements and terminology of one to the > other is not a good idea.____ > > draft-ietf-intarea-tunnels propose to decrease reassembly buffer to > “typical host EMTU_R (1500B) minus tunnel outer headers overhead” that would > cause additional fragmentation.____ > > __ __ > > As the compromise:____ > > Could you change the default for “draft-ietf-intarea-tunnels Tunnel MTU” > (reassembly buffer) to 9k? (to reflect reality)____ > > I would still be not happy in the mail to any alias about calling > parameters of transit node buffer by the terminology of end node buffer.____ > > But if you would not create additional fragmentation – I would not have > any complains in my draft in regards to draft-ietf-intarea-tunnels. ____ > > It could be the resolution.____ > > __ __ > > Well, probably it is not a good compromise, because you have the logic > through all your document. 9k (reality) would protrude out of your logic.____ > > The logic itself is good. It is broken because the most basic assumption > is wrong (before you did apply any logic).____ > > __ __ > > *The Data Plane on transit nodes should not behave____* > > *as the Control Plane on transit nodes or Transport Layer on end > nodes!____* > > It was the wrong assumption initially. Buffers should be different. Names > should be different. Unification here is not possible.____ > > It would be rejected by vendors anyway because reassembly is expensive, > the one who would increase it – would get a competitive disadvantage.____ > > It is easy to translate additional reassembly to $$ losses.____ > > __ __ > > Eduard____ > > *From:*Joseph Touch [mailto:[email protected] > <mailto:[email protected]>] > *Sent:* Tuesday, March 23, 2021 10:44 PM > *To:* Vasilenko Eduard <[email protected] > <mailto:[email protected]>> > *Cc:* [email protected] <mailto:[email protected]>; int-area <[email protected] > <mailto:[email protected]>> > *Subject:* Re: Proxy function for PTB messages on the tunnel end____ > > __ __ > > __ __ > > > > ____ > > On Mar 23, 2021, at 12:10 PM, Vasilenko Eduard > <[email protected] <mailto:[email protected]>> wrote:____ > > __ __ > > Hi Joseph,____ > > I am not much interested to discuss IPv4 now. (despite that 2 MTUs > for one interface is absent there too)____ > > Let’s look at your reference to RFC 8200.____ > > Section 4.5: unlike IPv4, fragmentation in IPv6 is performed only by > source nodes, not by routers along a packet's delivery path____ > > It means that all these discussions about fragmentation and > reassembly are not related to transit nodes. It is for the “source and > destination nodes”.____ > > __ __ > > Agreed. > > > ____ > > The better terminology is “transit node”, “destination node” – like > it is in RFC 8200, not “host” or “router”.____ > > __ __ > > Please see section 2 of RFC8200 (color added by me):____ > > __ __ > > > 2 <https://tools.ietf.org/html/rfc8200#section-2>. Terminology____ > > __ __ > > __ __ > > node a device that implements IPv6.____ > > __ __ > > *router* a node that forwards IPv6 packets not explicitly____ > > addressed to itself. (See Note below.)____ > > __ __ > > *host* any node that is not a router. (See Note below.)____ > > __ __ > > The term “transit node” does no appear in RFC8200.____ > > __ __ > > The terms “source node” and “destination node” are used in RFC8200 but > not defined in Sec 2. They are clearly hosts that originate IPv6 packets and > hosts that consume IPv6 packets, respectively.____ > > __ __ > > In an IPv6 tunnel, the tunnel ingress emits new packets with IP headers > it adds using its IP address. That makes it a source node. Same for how the > egress consumes those packets. ____ > > __ __ > > From the perspective of the tunnel path, the ingress and egress are hosts > and intermediate hop relays are routers.____ > > __ __ > > From the perspective of the overall path, the tunnel is a link, either > host/host, host/router, router/host, or router/router. A tunnel is not itself > a router, however.____ > > __ __ > > __ __ > > You see – nobody is asking vendors to be compliant with any > reassembly buffers in transit. Because it was assumed that would be not > reassembly at transit.____ > > __ __ > > Reassembly happens at tunnel egresses whether you want it to or not. ____ > > > > ____ > > Hence, vendors had the freedom to choose a much bigger number than > 1500 when reassembly did happen in reality (despite IPv6 architecture > decisions).____ > > __ __ > > 1500 is the IPv5 minimum EMTU_R; vendors can always implement larger > reassembly when they choose to.____ > > > > ____ > > Please, show any evidence (or just claim if you could not disclose) > that any vendor has 1500B (or less) for reassembly in the data plane (on > transit node).____ > > __ __ > > Here’s how to do it:____ > > - set interfaces to use 1280B packets____ > > - setup an IPv6 tunnel____ > > - send a 1280B packet through that tunnel____ > > __ __ > > If you don’t implement reassembly, it won’t work. But it does. > Everywhere.____ > > __ __ > > I neither know nor care. That’s a compliance issue, not a standards > issue.____ > > It is not a compliance issue, because there is no regulation/standard > to comply with. Vendors had the freedom and solved the problem easily.____ > > __ __ > > RFC8200 is the standard. Tunnel ingresses and egresses create and consume > packets, so they act as hosts. I don’t care if they’re implemented on > routers; routers implement lots of things as hosts (see e.g., RFC4201, Sec > 3.1:____ > > __ __ > > ...A compliant host____ > > implementation MUST support (a) and (c) and a compliant security____ > > gateway must support all three of these forms of connectivity, > since____ > > under certain circumstances a security gateway *acts as a host*____ > > __ __ > > This is described in detail in:____ > > RFC1858____ > > RFC4459____ > > RFC4944____ > > RFC6946____ > > RFC6980____ > > RFC7588____ > > RFC8021____ > > RFC8900____ > > I did not ask for a general discussion. Of course, fragmentation is a > big topic with many publications.____ > > __ __ > > You asked for *specific examples* of what vendors do. Those RFCs provide > them.____ > > > > ____ > > I did ask for any evidence that there is 2 MTU per 1 virtual > interface and fragmentation problem as the result of this (when packet would > come in between of these MTUs).____ > > ____ > > I don’t see why you’re stuck on this issue.____ > > Because you are trying to introduce additional fragmentation to the > area where it was absent before. The root cause is the introduction of the > second MTU per interface (that is in the reality the buffer size).____ > > __ __ > > I have not introduced anything; I am describing an existing requirement > of any device that consumes IP packets (i.e., acts as an IP destination). > When it does so, it is a host. Tunnel egresses do that.____ > > > > ____ > > 2 MTUs for one interface is the innovation. It does not exist in any > standard or any real implementation. It is invented only in > draft-ietf-intarea-tunnels. ____ > > It is not just new names and new classification. It new things that > does not exist in the real world. Harmful, because of additional > fragmentation introduced..____ > > __ __ > > Draft-tunnels has been discussed and reviewed by int-area for over a > decade. Nobody else has agreed with your assertions.____ > > __ __ > > Joe____ > > _______________________________________________ > v6ops mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
