Hi, Brian, See comments below…
Joe > On Sep 15, 2018, at 3:32 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > > Dear 杨术, > > I have added Joe Touch in Cc because one point below overlaps > with his TSVART review. > On 2018-09-16 06:41, 杨术 wrote: >> Dear Brian, >> >> Thank you very much for your comments, the following is the response, >> >>> “One of the authors (Shu Yang) stated that the Bitway company (a networking >>> device company in China) have implemented a prototype." >>> Note that the -00 draft was published in 2011. Not exactly fast progress >>> in the market. >> >> We have made more progress in these years, Bitway has already implemented >> it and deployed it in about 100 universities in CERNET2. > > That's good to know. (I like the concept of an Implementation Status > section as described in RFC7942, and I wish that all WGs would use this.) > > Now back to the fragmentation issue. Thank you for the new text: > > 7.3. Fragmentation > > The encapsulation performed by an upstream AFBR will increase the > size of packets. As a result, the outgoing I-IP link MTU may not > accommodate the larger packet size. It is not always possible for > core operators to increase the MTU of every link, thus fragmentation > after encapsulation and reassembling of encapsulated packets MUST be > supported by AFBRs [RFC5565]. The specific requirements for > fragmentation and tunnel configuration COULD be referred to in > [I-D.ietf-intarea-tunnels], which is under revision currently. > > One of my problems remains, and is not answered by draft-ietf-intarea-tunnels: > >>> But more seriously, if I-IP is IPv6, how does the originator of the IPv6 >>> packet (the AFBR) know that it needs to include a fragment header? >>> Is there some kind of hidden PMTUD process, or is this configured? >> >>> (I assume we are not so interested in the case that I-IP is IPv4, but >>> then the issue is that the AFBR MUST NOT set the DF bit.) > > draft-ietf-intarea-tunnels does cover the setting of DF, but it still > doesn't state how the tunnel end point knows when to include an IPv6 > fragment header, unless I missed something. If IPv6 fragmentation is needed, then the frag header is included. Otherwise, it is not. As per the standard. There’s no “DF” in IPv6 because on-path fragmentation isn’t possible. > I'm not sure whether this > needs discussion in the present draft or in Joe's draft, which is why > I added the Cc. > > Also I feel that the reference to draft-ietf-intarea-tunnels > should be normative, because I think an implementor needs to get > this right. Draft-ietf-intarea-tunnels is currently slated for BCP, not standards-track. I don’t recall if that matters for standards-track docs or whether it’s considered a down-ref. Joe _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
