IETF Logo Mail Archive

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

Joe Touch <touch@strayalpha.com> Mon, 03 June 2019 00:49 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2982C12004E; Sun, 2 Jun 2019 17:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.218
X-Spam-Level:
X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOATkn_MVfgd; Sun, 2 Jun 2019 17:49:01 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CCF4120020; Sun, 2 Jun 2019 17:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Content-Type:Mime-Version:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QhFW8m/vKVjheBhFQHY6lRDbr5j8HGgiLVfUNmJu7Pg=; b=X/WvCQkESyg/qxybP1mHsX4qS 2gbsQRF2DeEd76YiwNQ/vVj2Tj+Ii3KmYlkHcVwf6fB2kkqLZajKTETLLKTakEeGpJTlTRw4kjaqR sBd/HHCbOfdddpMgK4PW/oDgq+iZsgij5uPyBStaqWWeQ4YEPpX5IeMLlIu9V0R6qIz3XU51o3r5R KQtCdeQ1DvSfbXEoiWHHZEnlHJk0kjPz4wsBa0YkhZALQQLogzlgJLZU4cXODi4AKNHqO9AD9vjxY ogAlPmL3KgDvoeOfnYfFc541Ez1pBhLrmvp7ycw2iVTnLOcuLKCzYy1Tqi2qvXyvHGyqh+FqICBy/ XYQSE9F1Q==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58309 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1hXb9j-001QOA-AH; Sun, 02 Jun 2019 20:49:00 -0400
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_91EA00E4-E37A-4404-A65F-4FF55A941277"
From: Joe Touch <touch@strayalpha.com>
X-Priority: 3
In-Reply-To: <tencent_5AE1A70B6BACA93856FB1337@qq.com>
Date: Sun, 02 Jun 2019 17:48:53 -0700
Cc: tsv-art <tsv-art@ietf.org>, softwires <softwires@ietf.org>, ietf <ietf@ietf.org>, "draft-ietf-softwire-mesh-multicast.all" <draft-ietf-softwire-mesh-multicast.all@ietf.org>
Message-Id: <D0F86E8C-3174-4DBC-AEF5-DFC069CEA193@strayalpha.com>
References: <tencent_5AE1A70B6BACA93856FB1337@qq.com>
To: 杨术 <yangshu@oudmon.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/OulxEibJYWeU54STFSBZQiBXY-8>
Subject: Re: [Softwires] [Tsv-art] Tsvart last call review of draft-ietf-softwire-mesh-multicast-22
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2019 00:49:04 -0000

Hi, Shu,

> On Jun 2, 2019, at 8:31 AM, 杨术 <yangshu@oudmon.com> wrote:
> 
> 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

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

v2.23.0 | Report a Bug | By Email