Hi, Brian,
On 9/16/2018 3:59 PM, Brian E Carpenter wrote: >>> 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). > Yes to the above, but as I understand the draft, the AFBR *is* the tunnel > ingress, otherwise I wouldn't have an issue. There's no "just in case" for the IPv6 header. This tunnel ingress needs to do what all tunnel ingresses need to do - send the packet, which means source fragmentation if needed, which means including the frag header in IPv6 if source fragmented only. > >>> 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. > No, it isn't, but as far as I can see, any tunnel spec needs to state how > this applies. If the tunnel keeps no packet state, how is it going to perform > PMTUD? If the answer is that the tunnel end points need to be configured in > some way, that needs to be stated too. Perhaps... (see below). > Sorry to go on, but when I review a draft, I like to feel that if I had to, I > could code it, and in this case I just don't know how I would code the AFBR > with respect to PMTUD and/or including a fragment header. The tunnel ingress in this case is emitting packets toward a destination - that's a typical host function. There is no more - or less - requirement here for the source to figure out the correct MTU and use source fragmentation appropriately than for any other source. Joe
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
