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
------------------
杨术
欧德蒙科技有限公司
This message may contain privileged and confidential information only for the
use of the addressee named above. If you are not the intended recipient of this
message you are hereby notified that any use, distribution or reproduction of
this message is prohibited. If you have received this message in error please
notify the sender immediately.
------------------ Original ------------------
From: "Joseph Touch"<to...@strayalpha.com>;
Date: Wed, Sep 5, 2018 12:37 PM
To: "tsv-art"<tsv-...@ietf.org>;
Cc: "softwires"<softwires@ietf.org>; "ietf"<i...@ietf.org>;
"draft-ietf-softwire-mesh-multicast.all"<draft-ietf-softwire-mesh-multicast....@ietf.org>;
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)
------
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
