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

[Brian E Carpenter <[e-mail]>]

On 2018-09-17 10:28, Joe Touch wrote:
> Hi, Brian,
> 
>> On Sep 16, 2018, at 1:44 PM, Brian E Carpenter <[e-mail]> 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 <[e-mail]> 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).

Yes to the above, but as I understand the draft, the AFBR *is* the tunnel ingress, otherwise I wouldn't have an issue.
 
>> 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.

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.

   Brian

> 
> 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
> 
>