Re: [Gen-art] [Softwires] Genart last call review of draft-ietf-softwire-mesh-multicast-22
Joe Touch <touch@strayalpha.com> Sun, 16 September 2018 22:29 UTC
Return-Path: <touch@strayalpha.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B25F130DFB; Sun, 16 Sep 2018 15:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham 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 48Ymhsf2EIMy; Sun, 16 Sep 2018 15:28:57 -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 7EDBE130DF3; Sun, 16 Sep 2018 15:28:56 -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:Subject:Mime-Version:Content-Type: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=7IFRWRef+6X1yYd4RsWSRhjedZtyFvyhlXtf+s5BEIo=; b=C0lmXV9Zg3vRpzHiAUN9I8UGU VBNJN+tFna+pGgvGja0KUgoxpVwR95GnZ7scjPcQgZOf3XARqIsbnwZxYFh6A9/jK3sxCKoo3YAXm bcPIYtp8KNMXOYeaEwap3eeewb7Nwvl3QDHkvmRp9Ir9b3FvHnigRPggbp+bPCHJOpxS8yoLNaXM5 aWze44ISsDrt8rjj8ut/C27faBgx/NSTPv1HpkLtQGhljUxxYAExRpldNwQp0GvEhFUAjtG/B3UOi IZehYlH0jFO859EynVfEXB8qS1IKhnj4GdY3lvSylXX606vzKrl6FC91/6ZKIBawiIiRRarY5lOlI OSDkwTXbw==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:54181 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 1g1fXB-003GSX-P4; Sun, 16 Sep 2018 18:28:54 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_A67E1134-9B67-4573-9BF9-66C3FB02FD62"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <c6c4bcf3-1164-9296-98ff-386f850b5b76@gmail.com>
Date: Sun, 16 Sep 2018 15:28:52 -0700
Cc: 杨术 <yangshu@oudmon.com>, gen-art <gen-art@ietf.org>, softwires <softwires@ietf.org>, "draft-ietf-softwire-mesh-multicast.all" <draft-ietf-softwire-mesh-multicast.all@ietf.org>
Message-Id: <045AAF76-DB2D-4AC7-8A00-03811401A114@strayalpha.com>
References: <153532652678.11793.13628771343783380767@ietfa.amsl.com> <tencent_4B74746E333CB9DE0327BF0B@qq.com> <4b72b927-0e46-f471-a252-b447d2db0d78@gmail.com> <934AFCAD-C015-4FF7-A229-1867880DD922@strayalpha.com> <c6c4bcf3-1164-9296-98ff-386f850b5b76@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.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/gen-art/p-HL-t1PmvTIizk3ZmE5-XmsqmU>
Subject: Re: [Gen-art] [Softwires] Genart last call review of draft-ietf-softwire-mesh-multicast-22
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Sep 2018 22:29:01 -0000
Hi, Brian, > On Sep 16, 2018, at 1:44 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > > Hi Joe, > On 2018-09-17 05:15, Joe Touch wrote: >> Hi, Brian, >> >> See comments below… >> >> Joe >> >>> On Sep 15, 2018, at 3:32 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: >>> >>> Dear 杨术, >>> >>> I have added Joe Touch in Cc because one point below overlaps >>> with his TSVART review. >>> On 2018-09-16 06:41, 杨术 wrote: >>>> Dear Brian, >>>> >>>> Thank you very much for your comments, the following is the response, >>>> >>>>> “One of the authors (Shu Yang) stated that the Bitway company (a networking >>>>> device company in China) have implemented a prototype." >>>>> Note that the -00 draft was published in 2011. Not exactly fast progress >>>>> in the market. >>>> >>>> We have made more progress in these years, Bitway has already implemented >>>> it and deployed it in about 100 universities in CERNET2. >>> >>> That's good to know. (I like the concept of an Implementation Status >>> section as described in RFC7942, and I wish that all WGs would use this.) >>> >>> Now back to the fragmentation issue. Thank you for the new text: >>> >>> 7.3. Fragmentation >>> >>> 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]. The specific requirements for >>> fragmentation and tunnel configuration COULD be referred to in >>> [I-D.ietf-intarea-tunnels], which is under revision currently. >>> >>> One of my problems remains, and is not answered by draft-ietf-intarea-tunnels: >>> >>>>> But more seriously, if I-IP is IPv6, how does the originator of the IPv6 >>>>> packet (the AFBR) know that it needs to include a fragment header? >>>>> Is there some kind of hidden PMTUD process, or is this configured? >>>> >>>>> (I assume we are not so interested in the case that I-IP is IPv4, but >>>>> then the issue is that the AFBR MUST NOT set the DF bit.) >>> >>> draft-ietf-intarea-tunnels does cover the setting of DF, but it still >>> doesn't state how the tunnel end point knows when to include an IPv6 >>> fragment header, unless I missed something. >> >> If IPv6 fragmentation is needed, then the frag header is included. Otherwise, it is not. As per the standard. > > Yes, but my question is: How does the AFBR (the IPv6 source node) *know* > that fragmentation is needed? Path MTU discovery for the tunnel - at worst, based on the tunnel interface MTU. This is discussed in Section 4.2.3 of the draft-ietf-intarea-tunnels. > This question doesn't arise for IPv4; > if you don't set DF, you don't need to worry about PMTU size. For IPv4 as an outer header, yes - but see RFC 6864. Clearing DF means the tunnel ingress MUST generate new packets at a rate where it can ensure the IP IDs don’t cycle where fragments overlap (which is also already discussed in the section indicated above. > >> There’s no “DF” in IPv6 because on-path fragmentation isn’t possible. > > Exactly, so the absence of a fragment header forbids it. No, IPv6 forbids on-path fragmentation of an existing header only. The IPv6 tunnel encapsulation header isn’t on-path per se; it’s completely valid to encapsulate a received IPv6 packet inside an IPv6 tunnel that fragments *at the outer layer* (i.e., reassembling at the tunnel egress). > So should > the AFBR include a frag header just in case? That won’t help. The frag header would be generated at the tunnel ingress and has to be unique there (which has no relation to a frag header of the inner packet, if one is present). > Should this be > configurable? Should it use some form of PMTUD? Or do we require > the actual PMTU to be big enough? See the section above; you either need to discover it dynamically or deploy the system so it’s not an issue. > I see this as a gap in the specification. I don’t think it’s unique to this particular tunnel approach, though. Joe > Question to the authors: what does the Bitway implementation do? > Does it include a fragment header, or is the MTU simply configured > to be big enough? > > Brian > >> >>> I'm not sure whether this >>> needs discussion in the present draft or in Joe's draft, which is why >>> I added the Cc. >>> >>> Also I feel that the reference to draft-ietf-intarea-tunnels >>> should be normative, because I think an implementor needs to get >>> this right. >> >> Draft-ietf-intarea-tunnels is currently slated for BCP, not standards-track. I don’t recall if that matters for standards-track docs or whether it’s considered a down-ref. >> >> Joe
- [Gen-art] Genart last call review of draft-ietf-s… Brian Carpenter
- Re: [Gen-art] [Softwires] Genart last call review… 杨术
- Re: [Gen-art] [Softwires] Genart last call review… Brian E Carpenter
- Re: [Gen-art] [Softwires] Genart last call review… Joe Touch
- Re: [Gen-art] [Softwires] Genart last call review… Brian E Carpenter
- Re: [Gen-art] [Softwires] Genart last call review… Joe Touch
- Re: [Gen-art] [Softwires] Genart last call review… Brian E Carpenter
- Re: [Gen-art] [Softwires] Genart last call review… Joe Touch
- Re: [Gen-art] [Softwires] Genart last call review… Ole Troan
- Re: [Gen-art] [Softwires] Genart last call review… Brian E Carpenter