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

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

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