Dear Joseph,
Thank you for your comments.
About fragmentation, we modified this part as following:
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]. PMTUD [RFC8201] SHOULD be enabled and that ICMPv6 packets must not be filtered in the I-IP network. Using tunnel will reduce the effective MTU of the datagram. When the original packet size exceeds the effective MTU, fragmentation MUST happen after encapsulation on the upstream AFBR, and reassembly MUST happen before decapsulation on the downstream AFBR. Fragmentation and tunnel configuration considerations are provided in [RFC5565] and [I-D.ietf-intarea-tunnels]. The detailed procedure can be referred in Section 7.2 of [RFC2473].
about TTL, we also add a pointer to draft-ietf-intarea-tunnels.Best Regards,Shu Yang
------------------
------------------ Original ------------------
Date: Wed, Sep 5, 2018 12:37 PM
To: "tsv-art"<tsv-art@xxxxxxxx>;
Cc: "softwires"<softwires@xxxxxxxx>; "ietf"<ietf@xxxxxxxx>; "draft-ietf-softwire-mesh-multicast.all"<draft-ietf-softwire-mesh-multicast.all@xxxxxxxx>;
Subject: Tsvart last call review of draft-ietf-softwire-mesh-multicast-22
Reviewer: Joseph Touch
Review result: Ready with Issues
Hi, all,
I’ve prepared this review the request of Magnus Westerlund, who is preparing a
TSVART review. My comments focus on the issue of fragmentation and tunneling.
These are relatively minor issues that are simple to address, but not quite
what I would consider nits.
Joe
------
-- Regarding fragmentation:
The doc does the right thing by not trying to describe a solution
itself. However, it cites RFC 5565, which cites RFC4459. That's where
the only trouble lies - 4459 is incorrect, as noted in
draft-ietf-intarea-tunnels. I might suggest they continue to cite RFC
5565 but indicate that the requirements for tunneling are under current
revision and cite draft-ietf-intarea-tunnel (at least informationally) too.
It might also be important to discuss the challenge of tunnel
configuration in a multicast environment, which is addressed as well in
draft-ietf-intarea-tunnels.
- other issues:
7.2 correctly notes that the TTL should be set per tunneling policy, but
gives no advice as to how that is done (again, a pointer to
draft-ietf-intarea-tunnels would be useful)
------
Review result: Ready with Issues
Hi, all,
I’ve prepared this review the request of Magnus Westerlund, who is preparing a
TSVART review. My comments focus on the issue of fragmentation and tunneling.
These are relatively minor issues that are simple to address, but not quite
what I would consider nits.
Joe
------
-- Regarding fragmentation:
The doc does the right thing by not trying to describe a solution
itself. However, it cites RFC 5565, which cites RFC4459. That's where
the only trouble lies - 4459 is incorrect, as noted in
draft-ietf-intarea-tunnels. I might suggest they continue to cite RFC
5565 but indicate that the requirements for tunneling are under current
revision and cite draft-ietf-intarea-tunnel (at least informationally) too.
It might also be important to discuss the challenge of tunnel
configuration in a multicast environment, which is addressed as well in
draft-ietf-intarea-tunnels.
- other issues:
7.2 correctly notes that the TTL should be set per tunneling policy, but
gives no advice as to how that is done (again, a pointer to
draft-ietf-intarea-tunnels would be useful)
------
