Hi Fred, inline ..
On 9/23/14 4:14 PM, "Templin, Fred L" <[email protected]> wrote: >Hi Sri, > >> -----Original Message----- >> From: Sri Gundavelli (sgundave) [mailto:[email protected]] >> Sent: Tuesday, September 23, 2014 4:06 PM >> To: Templin, Fred L; [email protected] >> Subject: Re: Signaling Message Fragmentation >> >> Hi Fred, >> >> Thanks for your response and also sorry for the delay in catching up on >> this thread; Had to focus on some other business. >> >> The issue that I raised is specifically in the context of control plane >> messages. Some of the mobility options (Ex: Dynamic Mobile Network >>Prefix >> option in RFC7148) can easily exceed the path MTU size. Each of these >> options by itself may not be huge, but multiple instances of the option >> can be included in the message. For Mobile Networks use-case, its >>possible >> a mobile node is assigned a set of IPv6 prefixes and based on the count >> exceed the MTU limits. As such this should be OK; But ensuring >> fragmentation in the MIP layer eliminates issues such as dropped >>fragments >> by mid-level boxes and also fragmentation by on-path nodes. The question >> is also not about requiring a huge buffer sizes, but more about handling >> messages which are slightly beyond the MTU sizes. I will look at the >>SEAL >> proposal and understand how its handled there. > >Probably better to look at the latest AERO spec (posted today). >I have it fixed there now. Ack. Will take a look > >> For user-plane we are covered, the tunnel entry and exit point perform >> fragmentation prior to the encapsulation and so generally this should >>not >> cause any issues. We always have the ability to advertise a lower MTU >> value on the access link; The MTU value that we advertise on the access >> link should be the lower of the link MTU on the WLAN link and the Tunnel >> MTU on the MAG-LMA path. This can be achieved by allowing the MAG to >> include the adjusted MTU value in the DHCP OFFER and IPv6 Router >> Advertisements. However, we realize not all mobile nodes honor the MTU >> option in the DHCPOFFER; But, at least on the addressing plane we can >> ensure we send the correct MTU values. > >I'm not much of a fan of advertised MTU values in RAs and such. It >may be OK if your tunnel is point-to-point, but I want good MTU >solution for NBMA tunnels where the MTU between neighbors A and B >may be vastly different than the MTU between neighbors A and C. Its a P2P tunnel and so the NBMA considerations may not be needed. > >I also want there to be a guaranteed minimum and an unlimited maximum. >With AERO, all paths are guaranteed to support a minimum MTU of 1500. >But, larger packets can also go through (unfragmented) if the path >MTU is sufficient. Ok. Regards Sri > >Thanks - Fred >[email protected] > >> RFC 5844: (IPv4 Traffic from the Mobile Node) >> " The DHCPOFFER message [RFC2131] sent to the mobile node MUST >> include the Interface MTU option [RFC2132]. The DHCP servers in >> the Proxy Mobile IPv6 domain MUST be configured to include the >> Interface MTU option. The MTU value SHOULD reflect the tunnel MTU >> for the bidirectional tunnel between the mobile access gateway and >> the local mobility anchor." >> >> RFC 5213: (IPv6 Traffic from the Mobile Node) >> >> 3. The mobile access gateway SHOULD add the MTU option, as specified >> in [RFC4861], to the Router Advertisement messages that it sends >> on the access link. This will ensure the mobile node on the link >> uses the advertised MTU value. The MTU value SHOULD reflect the >> tunnel MTU for the bi-directional tunnel between the mobile >> access gateway and the local mobility anchor. Considerations >> from Section 6.9.5 SHOULD be applied for determining the tunnel >> MTU value. >> >> >> >> Regards >> Sri >> >> >> On 9/23/14 8:50 AM, "Templin, Fred L" <[email protected]> wrote: >> >> >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
