Hi Joe, It looks from your description that you have at least read Section 3.13 of draft-templin-aerolink, because there are many similarities. However, AERO is more comprehensive in the way it minimizes fragmentation and turns off fragmentation when it is no longer needed. AERO also allows larger packets through even if they are larger than the maximum size the egress is capable of reassembling. There is no reason the egress' maximum reassembly unit needs to be as large as the largest packet that can traverse the tunnel in one piece.
Thanks - Fred [email protected] > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Thursday, April 02, 2015 8:06 AM > To: Templin, Fred L; Black, David; [email protected]; [email protected] > Cc: [email protected]; [email protected] > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > configuration > > > > On 4/2/2015 7:49 AM, Templin, Fred L wrote: > > Hi David, > > > >>> This is where we differ - there is nothing in this recommendation > >>> that is specific to GRE - the recommendation applies to any generic > >>> IPv6 encapsulation and is appropriate to only those use cases where > >>> shutting down the tunnel altogether is preferable to allowing the > >>> tunnel to fragment. This is a generic IPv6 encapsulation consideration; > >>> not a GRE consideration. > >> > >> The "running code" involved here is GRE. I am concerned that we lack > >> the foundation to update 2473 for all encapsulated protocols. > > > > I don't get that. Just write a 3-pager that says it is OK for any kind of > > tunnel to collapse if it gets into a state where fragmentation is needed; > > a halt-and-catch-fire clause. But, why would you even need an RFC for that? > > For the benefit of others, here's my view on this (as I posted to Fred > yesterday, which is where collapsing the tunnel comes from): > > defs: > ingress packet - what arrives at the tunnel ingress > > egress packet - what leaves at the tunnel egress > > tunnel packet - packet that traverses from the > ingress to egress, that contains > the ingress packet plus encapsulation > > tunnel MTU - MTU of the path between ingress and egress > of tunneled packets > > reassembly MTU - largest tunnel packet that can be > reassembled at the egress > > General rules (which apply to more than GRE; they should apply to ANY > tunnel that carries ANY packet): > > ingress packet <= (tunnel MTU - encapsulation) > send through the tunnel as one tunnel packet > > ingress packet > (reassembly MTU - encapsulation) > drop and send ICMP PTB back > > (tunnel MTU - encaps) < ingress packet <= (reassy MTU - encaps) > do one of the following: > > a) fragment at ingress and reassemble at egress > > b) drop and declare the link down to all further > traffic until a probe of size "reassy MTU" > succeeds to the egress > > (this is what Fred just called "halt and catch fire", > but it has an important property: > - stay down while the required tunnel MTU > cannot traverse without fragmentation > - come up when the required tunnel MTU > is supported) > > (a) is more robust but more expensive to implement > > The tunnel MTU is defined by the protocols over which the tunnel is > defined as transiting. > > The egress MTU is defined by the encapsulation protocol. > > Note: the (b) case is allowed because a link can always declare itself > down. What it should never do is fail to transit packets that should fit > while allowing other smaller packets to get through - i.e., a link > should never be allowed to redefine the specs of the type of protocol > link it intends to support. > > The rules are augmented a bit when the ingress packet can be re-fragmented: > > ingress packet <= (tunnel MTU - encapsulation) > send through the tunnel as one tunnel packet > > ingress packet > (reassembly MTU - encapsulation) > refragment the ingress packet to fit the tunnel MTU > > (tunnel MTU - encaps) < ingress packet <= (reassy MTU - encaps) > do one of the following: > a) fragment at ingress and reassemble at egress > > b) refragment the ingress packet to fit the tunnel MTU > > in this case, (b) is preferred > --- > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
