Re: [RTG-DIR] [Softwires] RtgDir review ofdraft-ietf-softwire-mesh-multicast-22.txt

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

Return-Path: <yangshu@oudmon.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3C8130E2A for <rtg-dir@ietfa.amsl.com>; Sat, 15 Sep 2018 11:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.392
X-Spam-Level:
X-Spam-Status: No, score=0.392 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, RCVD_IN_RP_RNBL=1.31, 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 O0dCSQHrgBrI for <rtg-dir@ietfa.amsl.com>; Sat, 15 Sep 2018 11:39:09 -0700 (PDT)
Received: from smtpbg202.qq.com (smtpbg202.qq.com [184.105.206.29]) (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 780BD12F1A5 for <rtg-dir@ietf.org>; Sat, 15 Sep 2018 11:39:09 -0700 (PDT)
X-QQ-GoodBg: 2
X-QQ-SSF: 00400000000000F0
X-QQ-FEAT: 8oHFcAoL8WPd4bGR94w8KEClEfZW/EzV66V7h9162BhtnvVuCr8+Z9ldtov17 /30sUtdKByAHbK2vzpi2+yj6jX+b+LSbAkb8RbUTdPub7GU3IqTxBX1vngXEOrz+kLRAiYK bDxbu49npmcEA4+oWBnEVAv7BJ5aKsDgnnXsLkbYnAqbPAPVpG1adHwEYIAxCMga8ITA9uP pnvkY6u8qu1oJCf1GZD+U7604De+jHnli+izaLoIZBAbFO8AkMK9QUcGcQudETOBByFFSaI imj4vOfIJxGEQ23gyxWpQaaznz1NN+s8RqwkQltCgk3CJxNuAX0wxJeUGq9F8uOpWzZg==
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 114.252.110.46
X-QQ-STYLE:
X-QQ-mid: bizmailvip85t1537036738t63259
From: 杨术 <yangshu@oudmon.com>
To: "N.Leymann" <N.Leymann@telekom.de>
Cc: softwires <softwires@ietf.org>, rtg-dir <rtg-dir@ietf.org>, "draft-ietf-softwire-mesh-multicast.all" <draft-ietf-softwire-mesh-multicast.all@ietf.org>, rtg-ads <rtg-ads@ietf.org>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_5B9D51C2_08F966A0_067738A2"
Content-Transfer-Encoding: 8bit
Date: Sun, 16 Sep 2018 02:38:58 +0800
X-Priority: 3
Message-ID: <tencent_0DA581E94F2F256201010FDE@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
References: <LEJPR01MB037757EA179E14B2AB3CA90098050@LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE>
In-Reply-To: <LEJPR01MB037757EA179E14B2AB3CA90098050@LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE>
X-QQ-ReplyHash: 2309971655
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:39:00 +0800 (CST)
Feedback-ID: bizmailvip:oudmon.com:qybgforeign:qybgforeign2
X-QQ-Bgrelay: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/U1PYJpwPKGG91K4ZXWD7qnDSiF0>
Subject: Re: [RTG-DIR] [Softwires] RtgDir review ofdraft-ietf-softwire-mesh-multicast-22.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Sep 2018 18:39:15 -0000

Dear Nic,
 


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


 
> Comments:
 
> The draft in general is in good shape. The problem description is clear as 
 
> well as the solution to the problem. Nevertheless it took almost 8 year in order 
 
> to go from first draft to last call and I wonder if there are any implementations 
 
> available (or if there are alternatives with a broader deployment).
 
 
 
Thank you for the comments, we cooperated with a router company in China called Bitway
 
and we have already implemented it and deployed it in about 100 universities in CERNET2.
 


 
> Minor Issues:
 
> - The relation to RFC8114 is a bit unclear.
 
> The draft references several times RFC8114 which describes a solution for delivering IPv4 
 
> Multicast over an IPv6 Multicast network. Draft-ietf-softwire-mesh-multicast describes also 
 
> a solution for IPv4-over-IPv6 Multicast. From a functional point of view the result is the same 
 
> and there are several similarities. I think the differences should be made more clear and 
 
> therefore also the motivation for a solution based on draft- ietf-softwire-mesh-multicast.
 


 
Thank you for the helpful advice, we have added a sentence as following:
 
[RFC8114] provides a solution for delivering IPv4 multicast services 
 
over an IPv6 network. But it mainly focuses on the DS-lite [RFC6333] scenario,
 
where IPv4 addresses assigned by a broadband service provider are shared among customers
 


 
> - The draft also mentions MPLS as protocol for the I-IP but the solution focusses at 
 
> IPv6 as I-IP. What role does MPLS play in the context of IPv6 as I-IP (if packets are 
 
> MPLS encapsulated in the inner IP network)? This should also be clarified.
 


 
Thank you for the detailed advice, we add a note as following: 
 
(in this document, we focus on IP multicast) 
 


 
> Nits:
 
> Section 3:
 
> “
 
>  o I-IP (Internal IP): This refers to IP address family that is
 
>  supported by the core network.  In this document, the I-IP is IPv6.
 
>  o E-IP (External IP): This refers to the IP address family that is
 
>  supported by the client network(s) attached to the I-IP transit core.
 
>  In this document, the I-IP is IPv6.
 
> “
 
> I think the last sentence should read as “In this document, the E-IP is IPv4”.
 
 
 
Thank you for pointing it out, we have already modified it.
 


 
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:  "N.Leymann"<N.Leymann@telekom.de>;
Date:  Mon, Sep 10, 2018 11:25 PM
To:  "rtg-ads"<rtg-ads@ietf.org>; 
Cc:  "softwires"<softwires@ietf.org>; "rtg-dir"<rtg-dir@ietf.org>; "draft-ietf-softwire-mesh-multicast.all"<draft-ietf-softwire-mesh-multicast.all@ietf.org>; 
Subject:  [Softwires] RtgDir review ofdraft-ietf-softwire-mesh-multicast-22.txt

 
  Hello, 
  
 I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 
  
 Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. 
  
 Document: draft-ietf-softwire-mesh-multicast-22.txt 
  Reviewer: Nicolai Leymann 
  Review Date: 09/06/18
  IETF LC End Date: date-if-known 
  Intended Status: Standards Track 
  
 Summary: 
 I have some minor concerns about this document that I think should be resolved before publication. 
  
 Comments: 
 The draft in general is in good shape. The problem description is clear as well as the solution to the problem. Nevertheless it took almost 8 year in order to go from first draft to last call and I wonder if there are any implementations available (or if there are alternatives with a broader deployment).
  
 Major Issues: 
 "No major issues found." 
  
 Minor Issues: 
 - The relation to RFC8114 is a bit unclear. 
 The draft references several times RFC8114 which describes a solution for delivering IPv4 Multicast over an IPv6 Multicast network. Draft-ietf-softwire-mesh-multicast describes also a solution for IPv4-over-IPv6 Multicast. From a functional point of view the result is the same and there are several similarities. I think the differences should be made more clear and therefore also the motivation for a solution based on draft- ietf-softwire-mesh-multicast.
 - The draft also mentions MPLS as protocol for the I-IP but the solution focusses at IPv6 as I-IP. What role does MPLS play in the context of IPv6 as I-IP (if packets are MPLS encapsulated in the inner IP network)? This should also be clarified.
  
 Nits: 
 Section 3:
 “
    o I-IP (Internal IP): This refers to IP address family that is
    supported by the core network.  In this document, the I-IP is IPv6.
  
    o E-IP (External IP): This refers to the IP address family that is
    supported by the client network(s) attached to the I-IP transit core.
    In this document, the I-IP is IPv6.
 “
 I think the last sentence should read as “In this document, the E-IP is IPv4”.
  
 Regards
  
 Nic