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

[Joe Touch <[e-mail]>]

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. There’s no “DF” in IPv6 because on-path fragmentation isn’t possible.

> 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