Telechat Review of draft-ietf-softwire-dslite-multicast-14
review-ietf-softwire-dslite-multicast-14-rtgdir-telechat-venaas-2017-01-12-00
Request | Review of | draft-ietf-softwire-dslite-multicast |
---|---|---|
Requested revision | No specific revision (document currently at 18) | |
Type | Telechat Review | |
Team | Routing Area Directorate (rtgdir) | |
Deadline | 2017-01-20 | |
Requested | 2016-12-29 | |
Requested by | Alvaro Retana | |
Authors | Mohamed Boucadair , Jacni Qin , Christian Jacquenet , Yiu Lee , Qian Wang | |
I-D last updated | 2017-01-12 | |
Completed reviews |
Intdir Early review of -12
by Zhen Cao
(diff)
Intdir Early review of -12 by Tim Chown (diff) Opsdir Last Call review of -14 by Jouni Korhonen (diff) Genart Last Call review of -14 by Francis Dupont (diff) Rtgdir Telechat review of -14 by Stig Venaas (diff) Genart Telechat review of -16 by Francis Dupont (diff) Opsdir Telechat review of -16 by Tim Chown (diff) |
|
Assignment | Reviewer | Stig Venaas |
State | Completed | |
Request | Telechat review on draft-ietf-softwire-dslite-multicast by Routing Area Directorate Assigned | |
Reviewed revision | 14 (document currently at 18) | |
Result | Has issues | |
Completed | 2017-01-12 |
review-ietf-softwire-dslite-multicast-14-rtgdir-telechat-venaas-2017-01-12-00
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-dslite-multicast-14.txt Reviewer: Stig Venaas Review Date: 2017-01-11 IETF LC End Date: 2017-01-12 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: The document is fairly easy to read, and the solution is technically sound and is well described. But a couple of statements are technically wrong and need to be corrected. A few more details could be added in some places, and there are a couple of very minor issues that make it less readable. Major Issues: No major issues found. Minor Issues: In 3 places the documents talks about the MLD querier where it instead should have said PIM Designated Router, or PIM DR. In section 2 we have this definition: Multicast B4 (mB4): a functional entity which supports an IGMP-MLD interworking function (refer to Section 6.1) that relays information conveyed in IGMP messages by forwarding the corresponding Multicast Listener Discovery (MLD) messages towards the MLD Querier in the IPv6 network. In addition, the mB4 decapsulates IPv4-in-IPv6 multicast packets. It is the DR, not the querier that needs the reports. The reports are sent by multicast to the all MLDv2-capable routers address though, which means that DR, querier (they may be the same), and potentially other routers on the link will get the report. Maybe you can skip some details and just say that mB4 sends an MLD report. In 4.2 we have this paragraph: The mB4 uses the G6 (and both S6 and G6 in SSM) to create the corresponding MLD Report message. The mB4 sends the Report message towards the MLD Querier in the IPv6 network. The MLD Querier (which usually acts as the PIMv6 Designated Router too) receives the MLD Report message and sends the PIMv6 Join to join the IPv6 multicast distribution tree. The MLD Querier can send either PIMv6 Join (*,G6) in ASM or PIMv6 Join (S6,G6) in SSM to the mAFTR. It should just say DR here as well. Also in In 6.1 it says: MLD messages are forwarded natively towards the MLD Querier located upstream in the IPv6 network (i.e., the first hop IPv6 router). It should refer to the PIM DR here as well, and figure 2 should be updated. More discussion about SSM vs ASM would be useful. In the last paragraph of section 1 you have some text about SSM versus ASM. would be good to point out that SSM and ASM IPv4 groups should be mapped to SSM and and ASM IPv6 groups respectively. That is, if an IPv4 group is an SSM group, then I believe the respective IPv6 group needs to be SSM as well. The same for ASM. In 4.2 it says: The mAFTR acts as the IPv4 DR to which the uPrefix64-derived S6 is connected. Shouldn't it say that the mAFTR acts as the IPv6 DR? Nits: I found a number of nits. In the abstract we have: This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses the IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to DS-Lite serviced customers. This make it sounds like a single IPv6 multicast tree is used for delivery of all IPv4 multicast. It would be better changing this to plural (or possible say an IPv6 multicast distribution tree). In first paragraph of section 1: DS-Lite [RFC6333] is a technique that rationalizes the usage of the remaining global IPv4 addresses during the transition period by sharing a single IPv4 address with multiple users. Rationalize is the wrong word here I believe. Perhaps it should say rations, limits or reduces? In second paragraph of section 2, [RFC7597] is not marked correctly as a reference, it is just text. In 4.2 we have this text: The mAFTR advertises the route of uPrefix64 with an IPv6 Interior Gateway Protocol (IGP), so as to represent the IPv4-embedded IPv6 source in the IPv6 multicast network, and to run the Reverse Path Forwarding (RPF) check procedure on incoming multicast traffic. It might sound like mAFTR is the router doing the RPF check. It might be good to clarify that it is announced to allow other IPv6 routers to perform RPF check. In 6.2 you have this example: As an illustration, if a packet is received from source 2001:db8::192.0.2.33 and needs to be forwarded to group ff3x:1000::233.252.0.1 Note that the latter is not a valid unicast prefix-based multicast address. It would be better to use something like ff3x:20:2001:db8::233.252.0.1. This is also the case in 7.4. In 6.5 there is an issue with the example. It has the address ff0e::db8::233.252.0.1. You cannot use :: twice. The section 7.5 heading is TTL/Scope, but it only discusses Scope. It might make sense to recommend copying the TTL value from the IPv4 packet to the IPv6 packet, and perhaps copying it back after decapsulation. I don't understand section 8.1.1 about co-locating MLD querier with the mAFTR. Doesn't that mean that the mAFTR is on the same link as the mB4? If that is the case, do you need IPv6 encapsulation at all? Would it make sense to consider the case where mB4 acts as an IPv6 PIM router, avoiding sending MLD reports? Appendix B discusses issues with mismatch of group membership protocols at mB4. The real issue, which is not mentioned, is if mB4 receives source specific (SSM) reports from IPv4 receivers, and the upstream IPv6 MLD router only supports MLDv1. Regards, Stig