> On Sep 15, 2018, at 11:40 AM, 杨术 <[email protected]> wrote:
>
> Thank you for your useful advices, we add draft-ietf-intarea-tunnel as a
> reference
> for fragment technology and ttl configuration.
>
> We have uploaded a new version:
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-mesh-multicast-23
> <https://datatracker.ietf.org/doc/html/draft-ietf-softwire-mesh-multicast-23>
>
> Best Regards,
>
> Shu Yang
Some suggestions:
TTL:
- should refer to “TTL or hop count” (IPv6 calls this hop count because it no
longer intends to reflect time, as was originally intended for IPv4)
- upon encapsulation, the outer header TTL/hopcount should be set by policy
(not technology), i.e., “as desired”
- upon decapsulation, the inner header TTL/hopcount should be modified by
policy as well. it might be useful to suggest that the inner one never be
incremented and that it might be decremented to reflect the cost of tunnel
forwarding, but it need not be modified at all
Fragmentation:
I’ve never seen “COULD” used this way and it’s incorrect. They ARE described in
that draft.
It would be more correct, IMO, to say:
The specific requirements for
fragmentation and tunnel configuration SHOULD follow the
recommendations in
[I-D.ietf-intarea-tunnels].
Joe_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
