Hi, Brian, > On Sep 16, 2018, at 1:44 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > > 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 >>> <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. > > Yes, but my question is: How does the AFBR (the IPv6 source node) *know* > that fragmentation is needed?
Path MTU discovery for the tunnel - at worst, based on the tunnel interface MTU. This is discussed in Section 4.2.3 of the draft-ietf-intarea-tunnels. > This question doesn't arise for IPv4; > if you don't set DF, you don't need to worry about PMTU size. For IPv4 as an outer header, yes - but see RFC 6864. Clearing DF means the tunnel ingress MUST generate new packets at a rate where it can ensure the IP IDs don’t cycle where fragments overlap (which is also already discussed in the section indicated above. > >> There’s no “DF” in IPv6 because on-path fragmentation isn’t possible. > > Exactly, so the absence of a fragment header forbids it. No, IPv6 forbids on-path fragmentation of an existing header only. The IPv6 tunnel encapsulation header isn’t on-path per se; it’s completely valid to encapsulate a received IPv6 packet inside an IPv6 tunnel that fragments *at the outer layer* (i.e., reassembling at the tunnel egress). > So should > the AFBR include a frag header just in case? That won’t help. The frag header would be generated at the tunnel ingress and has to be unique there (which has no relation to a frag header of the inner packet, if one is present). > Should this be > configurable? Should it use some form of PMTUD? Or do we require > the actual PMTU to be big enough? See the section above; you either need to discover it dynamically or deploy the system so it’s not an issue. > I see this as a gap in the specification. I don’t think it’s unique to this particular tunnel approach, though. Joe > 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
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
