> 1) How big?? Still no answer. I guess then we will have to assume 64KB. Anything larger than that will have to go as a jumbogram.
Thanks - Fred [email protected] > -----Original Message----- > From: dmm [mailto:[email protected]] On Behalf Of Templin, Fred L > Sent: Tuesday, September 23, 2014 10:30 AM > To: Sri Gundavelli (sgundave); [email protected] > Subject: Re: [DMM] Signaling Message Fragmentation > > Hi Sri, > > I will make this even easier and reduce it to a single question: > > 1) How big?? > > Thanks - Fred > [email protected] > > > -----Original Message----- > > From: Templin, Fred L > > Sent: Tuesday, September 23, 2014 8:51 AM > > To: Templin, Fred L; Sri Gundavelli (sgundave); [email protected] > > Subject: RE: Signaling Message Fragmentation > > > > Sri, > > > > > I've seen some work on IPSecme WG on IKEv2 message fragmentation > > > for the same issue. > > > > I looked at this, and the approach is roughly the same as what I have > > been talking about in SEAL [RFC5320][draft-templin-intarea-seal] for > > years. In other words, perform fragmentation and reassembly at a level > > above the encapsulating IP protocol headers and below the encapsulated > > IP protocol headers - a mid-layer fragmentation and reassembly. > > > > So, this brings up a few questions: > > > > 1) Does the concern apply only to large control messages, or also to > > large data packets? > > 2) How big can the control messages get - not only for just today but > > also going forward into the future? > > 3) Are we really so concerned about IP fragment dropping that we need > > to bump this up to a mid-layer frag/reass? > > > > Thanks - Fred > > [email protected] > > > > --- > > > > From: dmm [mailto:[email protected]] On Behalf Of Templin, Fred L > > Sent: Monday, September 22, 2014 4:45 PM > > To: Sri Gundavelli (sgundave); [email protected] > > Subject: Re: [DMM] Signaling Message Fragmentation > > > > Hi Sri, > > > > My understanding is that if a source sends fragmented messages it must have > > assurance > > that the destination has a large enough reassembly buffer. Since the > > minimum IPv6 > > reassembly unit is only 1500 bytes, the source SHOULD NOT send fragmented > > packets > > larger than 1500 bytes unless there is some other means of determining > > whether the > > destination's reassembly buffer can accommodate the larger size. > > > > How big do you need? > > > > Thanks - Fred > > > > From: dmm [mailto:[email protected]] On Behalf Of Sri Gundavelli > > (sgundave) > > Sent: Thursday, September 18, 2014 1:04 PM > > To: [email protected] > > Subject: [DMM] Signaling Message Fragmentation > > > > [Discussion under the maintenance scope] > > > > With the standardization of all the new mobility options (ANI, QoS, IFOM, > > MNP..etc) and specially > > with the NAI/Domain type fields in some of those options, we are almost > > close to hitting the PBU/BU > > fragmentation limit. > > > > Any thoughts on how to deal with this ? How is it solved in other message > > based protocols ? I've > seen > > some work on IPSecme WG on IKEv2 message fragmentation for the same issue. > > > > Should we do some thing here ? Or, if any one has invested time on this and > > has a proposal ? > Comments > > ? > > > > > > > > Regards > > Sri > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
