Hi Joe, On 2018-09-17 05:15, Joe Touch wrote: > Hi, Brian, > > See comments below… > > Joe > >> On Sep 15, 2018, at 3:32 PM, Brian E Carpenter <[email protected]> >> 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.
Yes, but my question is: How does the AFBR (the IPv6 source node) *know* that fragmentation is needed? This question doesn't arise for IPv4; if you don't set DF, you don't need to worry about PMTU size. > There’s no “DF” in IPv6 because on-path fragmentation isn’t possible. Exactly, so the absence of a fragment header forbids it. So should the AFBR include a frag header just in case? Should this be configurable? Should it use some form of PMTUD? Or do we require the actual PMTU to be big enough? I see this as a gap in the specification. Question to the authors: what does the Bitway implementation do? Does it include a fragment header, or is the MTU simply configured to be big enough? Brian > >> 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 > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
