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

[Joe Touch <[e-mail]>]

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

> 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