Hi Tom, > -----Original Message----- > From: Tom Herbert [mailto:t...@herbertland.com] > Sent: Friday, February 01, 2019 8:15 AM > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > Cc: Joe Touch <to...@strayalpha.com>; Ron Bonica <rbon...@juniper.net>; > int-area <int-area@ietf.org> > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt > > On Fri, Feb 1, 2019 at 7:39 AM Templin (US), Fred L > <fred.l.temp...@boeing.com> wrote: > > > > Hi Tom, > > > > > -----Original Message----- > > > From: Tom Herbert [mailto:t...@herbertland.com] > > > Sent: Thursday, January 31, 2019 5:17 PM > > > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > > > Cc: Joe Touch <to...@strayalpha.com>; Ron Bonica <rbon...@juniper.net>; > > > int-area <int-area@ietf.org> > > > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt > > > > > > On Thu, Jan 31, 2019 at 5:03 PM Templin (US), Fred L > > > <fred.l.temp...@boeing.com> wrote: > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Tom > > > > > Herbert > > > > > Sent: Thursday, January 31, 2019 4:40 PM > > > > > To: Joe Touch <to...@strayalpha.com> > > > > > Cc: Ron Bonica <rbon...@juniper.net>; int-area <int-area@ietf.org> > > > > > Subject: Re: [Int-area] I-D Action: > > > > > draft-ietf-intarea-frag-fragile-06.txt > > > > > > > > > > On Thu, Jan 31, 2019 at 3:10 PM Joe Touch <to...@strayalpha.com> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2019-01-31 13:56, Tom Herbert wrote: > > > > > > > > > > > > On Thu, Jan 31, 2019 at 7:59 AM Joe Touch <to...@strayalpha.com> > > > > > > wrote: > > > > > > > > > > > > > > > > > > The problem with dropping the entire paragraph is the section title > > > > > > - talking about stateless firewalls begs the question of > > > stateful > > > > > ones. This is reinforced later in the recommendations. The sentences > > > > > you remove were the only thing that tied the two > together, > > > > > which IMO is important. > > > > > > > > > > > > > > > > > > Joe, > > > > > > > > > > > > The term "Stateless firewalls" is unambiguous in this context. In a > > > > > > stateless firewall, each packet is inspected and judge based solely > > > > > > on > > > > > > it's content. > > > > > > > > > > > > > > > > > > My statement above has no relation to any potential ambiguity in > > > > > > the term. > > > > > > > > > > > > --- > > > > > > > > > > > > However, the term stateless is inaccurate in a few places: > > > > > > > > > > > > (Sec 4.6) NAT is a stateful procedure for an otherwise stateless > > > > > > protocol as well. The same could be argued for load balancers > > > that > > > > > retain similar state through a connection for a flow (i.e., not just > > > > > hashing the flow or tuple, but doing round-robin per- > flow/tuple > > > > > 'sticky' routing) > > > > > > > > > > > > (Sec 7.3) The problem is not just stateless middle boxes, but also > > > > > > certain stateful ones (e.g., NATs, some load balancers, etc.) > > > > > > > > > > > > --- > > > > > > > > > > > > Thus "stateful" actually is both ambiguous and inaccurate here. > > > > > > > > > > > > You appear to want to distinguish between the state needed for > > > > > > virtual reassembly and the state needed to maintain NAT > > > > > translations or sticky round-robin load balancing, but there's no > > > > > simple term that differentiates them. They're both content- > > > > > dependent, context-dependent, and stateful. > > > > > > > > > > > > > > > > > > Further, as you note there are no *specified* algorithms for > > > > > > virtual reassembly, nor are there any *specified* for NAT > > > translation > > > > > table maintenance or sticky load balancing. Everyone comes up with > > > > > their own and the basic concept is well enough defined as > to > > > not > > > > > need a specification. > > > > > > > > > > > In that case, if it's so obvious and well defined then there shouldn't > > > > > be any issue in either providing a reference to a description or > > > > > specifying it in the draft (if authors do choose discuss virtual > > > > > reassembly in the draft). > > > > > > > > I have been telling everyone about virtual fragmentation reassembly for > > > > years. You will find it in many of my docs. Here is what cisco says > > > > about it: > > > > > > > > > > > > https://www.cisco.com/c/en/us/td/docs/ios/sec_data_plane/configuration/guide/12_4/sec_data_plane_12_4_book/sec_virt_frag_ > > > reassm.html > > > > > > Hi Fred, > > > > > > It does seem that Cisco configuration manuals and marketing materials > > > are the best source of information on virtual reassembly. > > > > > > https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_frre/configuration/xe-3s/frre-xe-3s-book/virt-frag-reassembly.html > > > is a little more interesting in that it provides a few more details. > > > In particular the requirement that all fragments must traverse the > > > same intermediate device is mentioned: > > > > > > "The reassembly process requires all fragments within an IP datagram. > > > If fragments within an IP datagram are sent to different devices due > > > to load balancing VFR may fail and fragments may be dropped." > > > > Yes, of course the fragments all need to go through the same destination > > where > > VFR is caching the fragments. That is assured due to the IP destination > > address > > for unicast, but not necessarily for anycast. But, for anycast, the > > considerations > > are no different for middleboxes than they are for anycast final > > destinations. > > > > An analogy for VFR is that the middlebox receives the pieces of a puzzle > > from > > the network. It checks each piece to make sure it is OK and holds them until > > all pieces have arrived, but then instead of assembling the puzzle it > > forwards > > the pieces on to the next hop destination, with the realization that there > > could > > be NATs-within-NATs. Then, when the final destination receives all pieces it > > assembles the puzzle. > > > > I don' t think there needs to be a spec for this because the behavior is > > inherently understood from the title (*Virtual* Fragment Reassembly). > > > Fred, > > I don't see this. It is not at all clear from three words that > everyone could draw the same conclusions on what the protocol is and > how it works. Your description above about the interaction between > multicast and unicast is not obvious from the title. Neither is it
I said "anycast"; not multicast. Multicast is different in that all nodes that are members of the group will receive all fragments. With anycast, only one node out of potentially many gets the fragments, and it may not always be the same node for all fragments. > obvious there is on only compliant way to implement the protocol > (there are at least three variants that have been implemented with > varying degrees of interoperability problems). I still maintain that > if virtual reassembly were to be used in a normative context, it needs > a normative definition. If nothing else, that ensures there is no > ambiguity in what the protocol is, how it works, and what > implementations need to do to be interoperable-- after all that is the > goal of formal protocol specifications. The only requirement is that the node receiving the fragments and doing VFR internally has to emit them looking just like they did originally - albeit with a potentially different IP destination address. What goes on inside the box in terms of VFR is completely implementation-dependent, and not a topic for standardization. Thanks - Fred > Tom > > > Thanks - Fred > > > > > Tom > > > > > > > > > > > Fred > > > > > > > > > > Tom > > > > > > > > > > > Joe > > > > > > > > > > _______________________________________________ > > > > > Int-area mailing list > > > > > Int-area@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
