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. 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.
...
>>> "9. Softwire Mesh Multicast Encapsulation
>>>
>>> Softwire mesh multicast encapsulation does not require the use of any
>>> one particular encapsulation mechanism. Rather, it MUST accommodate
>>> a variety of different encapsulation mechanisms, and allow the use of
>>> encapsulation mechanisms mentioned in [RFC4925]. Additionally, all
>>> of the AFBRs attached to the I-IP network MUST implement the same
>>> encapsulation mechanism."
>>
>> It isn't clear how this is achieved. Presumably it needs to be configured
>> in each AFBR? An operator needs to manage this somehow or other.
>
> Again, we add a pointer to draft-ietf-intarea-tunnel, which discuss about
> tunnel, fragmentation, ttl in more details.
True, but it does not answer my question. In the specific case
of softwire-mesh-multicast, how is that "MUST" achieved?
Perhaps all you need to say is:
Additionally, all
of the AFBRs attached to the I-IP network MUST be configured
to use the same encapsulation mechanism.
>> "(S,G) state" is a term of art that is not defined here, or in the
>> reference [RFC7899]. I think there should be a reference to [RFC7761]
>> where "(S,G) state" is first used; or define it in the Terminology
>> section.
>
> We add a reference to [RFC7761] each time when (S,G), (*, G), (S,G,rpt)
> is first used.
Thanks!
Brian
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
