Re: [Gen-art] [Softwires] Genart last call review ofdraft-ietf-softwire-mesh-multicast-22
" 杨术 " <yangshu@oudmon.com> Sat, 15 September 2018 18:41 UTC
Return-Path: <yangshu@oudmon.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 A7F3D130F0F; Sat, 15 Sep 2018 11:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.918
X-Spam-Level:
X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 Hj4NGPaabRmE; Sat, 15 Sep 2018 11:41:09 -0700 (PDT)
Received: from smtpbg339.qq.com (smtpbg339.qq.com [14.17.44.34]) (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 6F24B130E45; Sat, 15 Sep 2018 11:41:07 -0700 (PDT)
X-QQ-GoodBg: 2
X-QQ-SSF: 00400000000000F0
X-QQ-FEAT: p3khLl4f94hGpf84pvFlDo/YNmqmGAgAbAXL1nUXqvsibMLO4ILG7RFxtNrDO rJh9tPXGQ8EzAjlLJ/ToWwpVtFV+eGDqNtzBMuytbvtEA/CrRVv8Jc8avZUiGFH8Kn776eT 5/ZIIikl310bDp7TaDjemqUa6l71eTSIjkWoGa1CTAahOPpCskehbcfz2sZWQ6NKVq8jH5O sqdZfleiQGOy0U6Q1RHe4wiilHZY2ATTyGIVmUQlbgPCw8sQ2NWvVBy2MqNW7k7TDn+U9Ik hr8PpSAkysbDeOKXHMNlvgahJn/ajfbKySzeSTfohgk7CUN7fdcVx5q/Q=
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 114.252.110.46
X-QQ-STYLE:
X-QQ-mid: bizmailvip85t1537036861t67578
From: 杨术 <yangshu@oudmon.com>
To: Brian Carpenter <brian.e.carpenter@gmail.com>, gen-art <gen-art@ietf.org>
Cc: softwires <softwires@ietf.org>, "draft-ietf-softwire-mesh-multicast.all" <draft-ietf-softwire-mesh-multicast.all@ietf.org>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_5B9D523D_091BC148_1DECF4D9"
Content-Transfer-Encoding: 8bit
Date: Sun, 16 Sep 2018 02:41:01 +0800
X-Priority: 3
Message-ID: <tencent_4B74746E333CB9DE0327BF0B@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
References: <153532652678.11793.13628771343783380767@ietfa.amsl.com>
In-Reply-To: <153532652678.11793.13628771343783380767@ietfa.amsl.com>
X-QQ-ReplyHash: 2975945212
X-QQ-SENDSIZE: 520
Received: from qq.com (unknown [127.0.0.1]) by smtp.qq.com (ESMTP) with SMTP id ; Sun, 16 Sep 2018 02:41:02 +0800 (CST)
Feedback-ID: bizmailvip:oudmon.com:qybgweb:qybgweb3
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/ERBo2eybB9FeXaCxBAFjyeMgd-U>
Subject: Re: [Gen-art] [Softwires] Genart last call review ofdraft-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: Sat, 15 Sep 2018 18:41:23 -0000
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. > ”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. As it is not always possible for >> core operators to increase the MTU of every link. Fragmentation >> after encapsulation and reassembling of encapsulated packets MUST be >> supported by AFBRs [RFC5565]." > This is troublesome. Firstly, a nit: the 3rd sentence is not a sentence. > 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.) > The reference [RFC5565] doesn't help at all, because it just says the > MTU SHOULD be big enough to avoid fragmentation. Thanks for your helpful comments, we add draft-ietf-intarea-tunnel as a reference for fragmentation. >> “9. Softwire Mesh Multicast Encapsulation >> Softwire mesh multicast encapsulation does not require the use of any >> one particular encapsulation mechanism. Rather, it MUST accommodate >> a variety of different encapsulation mechanisms, and allow the use of >> encapsulation mechanisms mentioned in [RFC4925]. Additionally, all >> of the AFBRs attached to the I-IP network MUST implement the same >> encapsulation mechanism." > It isn't clear how this is achieved. Presumably it needs to be configured > in each AFBR? An operator needs to manage this somehow or other. Again, we add a pointer to draft-ietf-intarea-tunnel, which discuss about tunnel, fragmentation, ttl in more details. > “(S,G) state" is a term of art that is not defined here, or in the > reference [RFC7899]. I think there should be a reference to [RFC7761] > where "(S,G) state" is first used; or define it in the Terminology > section. We add a reference to [RFC7761] each time when (S,G), (*, G), (S,G,rpt) is first used. We have uploaded a new version: https://datatracker.ietf.org/doc/html/draft-ietf-softwire-mesh-multicast-23 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: "Brian Carpenter"<brian.e.carpenter@gmail.com>; Date: Mon, Aug 27, 2018 07:35 AM To: "gen-art"<gen-art@ietf.org>; Cc: "softwires"<softwires@ietf.org>; "draft-ietf-softwire-mesh-multicast.all"<draft-ietf-softwire-mesh-multicast.all@ietf.org>; Subject: [Softwires] Genart last call review ofdraft-ietf-softwire-mesh-multicast-22 Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-softwire-mesh-multicast-22 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-softwire-mesh-multicast-22.txt Reviewer: Brian Carpenter Review Date: 2018-08-27 IETF LC End Date: 2018-09-06 IESG Telechat date: Summary: Ready with issues -------- Comments: --------- "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. Issues: ------- "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. As it is not always possible for core operators to increase the MTU of every link. Fragmentation after encapsulation and reassembling of encapsulated packets MUST be supported by AFBRs [RFC5565]." This is troublesome. Firstly, a nit: the 3rd sentence is not a sentence. 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.) The reference [RFC5565] doesn't help at all, because it just says the MTU SHOULD be big enough to avoid fragmentation. "9. Softwire Mesh Multicast Encapsulation Softwire mesh multicast encapsulation does not require the use of any one particular encapsulation mechanism. Rather, it MUST accommodate a variety of different encapsulation mechanisms, and allow the use of encapsulation mechanisms mentioned in [RFC4925]. Additionally, all of the AFBRs attached to the I-IP network MUST implement the same encapsulation mechanism." It isn't clear how this is achieved. Presumably it needs to be configured in each AFBR? An operator needs to manage this somehow or other. Nits: ----- "(S,G) state" is a term of art that is not defined here, or in the reference [RFC7899]. I think there should be a reference to [RFC7761] where "(S,G) state" is first used; or define it in the Terminology section. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
- [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