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"<[email protected]>;
Date: Mon, Sep 10, 2018 11:25 PM
To: "rtg-ads"<[email protected]>;
Cc: "softwires"<[email protected]>; "rtg-dir"<[email protected]>;
"draft-ietf-softwire-mesh-multicast.all"<[email protected]>;
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_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
