Re: [Gen-art] [Softwires] Genart last call review of draft-ietf-softwire-mesh-multicast-22

[Joe Touch <[e-mail]>]

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