Re:[Softwires] Tsvart last call review ofdraft-ietf-softwire-mesh-multicast-22

" 杨术 " <yangshu@oudmon.com> Sat, 15 September 2018 18:40 UTC

Return-Path: <yangshu@oudmon.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D553130ECD for <ietf@ietfa.amsl.com>; Sat, 15 Sep 2018 11:40:32 -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 Q7aTe9z7rBwY for <ietf@ietfa.amsl.com>; Sat, 15 Sep 2018 11:40:27 -0700 (PDT)
Received: from smtpbgsg3.qq.com (smtpbgsg3.qq.com [54.179.177.220]) (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 E0AB3130E70 for <ietf@ietf.org>; Sat, 15 Sep 2018 11:40:26 -0700 (PDT)
X-QQ-GoodBg: 2
X-QQ-SSF: 00400000000000F0
X-QQ-FEAT: 5pbVbGB2o2tBOSRIN8LcCIg3Aq3xsig0n9i3DP9ozqyUMn7oyc9Zp08xmAeU5 RR9bjF8rn/aEc2VHy2+qbrotnWZYKIB3hO5QtYvfM4+u+Zp/kx5Fh8gNcp44iEijltGL4cv oAxgFP9Cp8y/9/IPIgRdtH/7gZojzqOklWJtUoWv8bUUGtABXTGYjvhtudMmY+iuXh0xwm1 8h2KmQGnCd5kzajMfgc0z3fm/UFE6lUhmXtmxA8RbbKzPL5vnyRiGNkq0m1rTqy7NqAT7/6 SZ7ikVHOQrEKNwEk1WRrUrgi2THCaJYt/AhfwOs3/Brec6alRXZsnsa1g=
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 114.252.110.46
X-QQ-STYLE:
X-QQ-mid: bizmailvip85t1537036810t94309
From: 杨术 <yangshu@oudmon.com>
To: Joseph Touch <touch@strayalpha.com>, tsv-art <tsv-art@ietf.org>
Cc: softwires <softwires@ietf.org>, ietf <ietf@ietf.org>, "draft-ietf-softwire-mesh-multicast.all" <draft-ietf-softwire-mesh-multicast.all@ietf.org>
Subject: Re:[Softwires] Tsvart last call review ofdraft-ietf-softwire-mesh-multicast-22
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_5B9D520A_0B1402A0_43C6BE25"
Content-Transfer-Encoding: 8bit
Date: Sun, 16 Sep 2018 02:40:10 +0800
X-Priority: 3
Message-ID: <tencent_780DA8CB0F3EF600533B7D45@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
References: <153612222105.14129.11979247184090243326@ietfa.amsl.com>
In-Reply-To: <153612222105.14129.11979247184090243326@ietfa.amsl.com>
X-QQ-ReplyHash: 1672933441
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:40:12 +0800 (CST)
Feedback-ID: bizmailvip:oudmon.com:qybgforeign:qybgforeign1
X-QQ-Bgrelay: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/dJJJU_qD2zTwr4eLv8W2_92nuNc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Sep 2018 18:40:41 -0000

Dear Joe,
 


 
Thank you very much for your comments, the following is the response, 
 


 
> 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)
 


 
Thank you for your useful advices, we add draft-ietf-intarea-tunnel  as a reference
 
for fragment technology and ttl configuration. 
 


 
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:  "Joseph Touch"<touch@strayalpha.com>;
Date:  Wed, Sep 5, 2018 12:37 PM
To:  "tsv-art"<tsv-art@ietf.org>; 
Cc:  "softwires"<softwires@ietf.org>; "ietf"<ietf@ietf.org>; "draft-ietf-softwire-mesh-multicast.all"<draft-ietf-softwire-mesh-multicast.all@ietf.org>; 
Subject:  [Softwires] Tsvart last call review ofdraft-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