Subject: Re: [Softwires] Tsvart last call review of draft-ietf-softwire-mesh-multicast-22

From: "杨术" <[email-masked]>
Date: Sun, 2 Jun 2019 23:31:22 +0800

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"<[email-masked]>;
Date:  Wed, Sep 5, 2018 12:37 PM
To:  "tsv-art"<[email-masked]>; 
Cc:  "softwires"<[email-masked]>; "ietf"<[email-masked]>; "draft-ietf-softwire-mesh-multicast.all"<[email-masked]>; 
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)

------

---

From: Joe Touch <[email-masked]>
Date: Sun, 2 Jun 2019 17:48:53 -0700

Hi, Shu,

> On Jun 2, 2019, at 8:31 AM, 杨术 <[email-masked]> wrote:
> 
> Dear Joseph,
> 
> 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

it might be useful to be specific - “source fragmentation” rather than “fragmentation”.

>    after encapsulation and reassembling of encapsulated packets MUST be
>    supported by AFBRs [RFC5565 <https://tools.ietf.org/html/rfc5565>].  PMTUD [RFC8201 <https://tools.ietf.org/html/rfc8201>] SHOULD be enabled and
>    that ICMPv6 packets must not be filtered in the I-IP network.  Using

“ICMPv6 packets MUST NOT be filtered in the …”

(i.e., delete “that” and capitalize MUST NOT.

>    tunnel will reduce the effective MTU of the datagram.  When the

This repeats the same idea - it isn’t needed.

>    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 <https://tools.ietf.org/html/rfc5565>] and
>    [I-D.ietf-intarea-tunnels <https://tools.ietf.org/html/draft-ietf-softwire-mesh-multicast-24#ref-I-D.ietf-intarea-tunnels>].  The detailed procedure can be referred
>    in Section 7.2 of [RFC2473] <https://tools.ietf.org/html/rfc2473#section-7.2>.
> 

I would suggest the following, which includes the suggestions above:

   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 source fragmentation
  after encapsulation and reassembling of encapsulated packets MUST be
   supported by AFBRs [RFC5565].  PMTUD [RFC8201] SHOULD be enabled and
   ICMPv6 packets MUST NOT be filtered in the I-IP network.   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].

Joe