I think that a decision should be made on this draft. If it is going to present a generic solution it could be fine but then such a draft does not meet Softwire charter item so it can not stay in Softwire.
My suggestion is to make it specific to DS-Lite so that it stays in Softwire and meets the charter item. I believe this was Alain's intention when he asked the two drafts to be merged. Regards, Behcet On Tue, Jun 12, 2012 at 3:34 AM, Jacni Qin <[email protected]> wrote: > Hi Stig, > > Sorry I missed the discussion, and your comments, inline please, hope it > won't be too late. > > On 6/8/2012 Friday 1:43 AM, Stig Venaas wrote: > > Here are my last call comments. I think substantial changes are > needed to the draft. > > I understand that this draft is focusing on dslite. But it appears that > it is a generic solution. As it says in the draft: > > An IPv4 receiver accesses IPv4 multicast contents over an IPv6- > only multicast-enabled network. > > Based on this, I think the scope of the draft, the title and > introduction etc should be updated to actually show that it is > a generic approach. And then instead list dslite as one of the > scenarios where this is needed. > > Since it is a generic approach, I think it should also be reviewed, > perhaps an additional WGLC, in mboned. pim wg may also have some > interest in reviewing it. There are some errors regarding pim in > this document. > > > In particular, it discussed translation of IGMP/MLD. This is a > topic that has been discussed in mboned/pim, and there is also > another draft discussing this. > > It refers to draft-ietf-mboned-64-multicast-address-format-01. If that > is to stay, I think this draft needs to wait to see what happens with > the address-format draft in 6man. Changes may be needed in this draft > depending on what happens. If only minor changes, the examples in this > draft may need to be updated. > > Thanks, it's true. We'll wait for the comments from 6man, and update it > accordingly if needed. > > > > Technical issue: > > In 4.2 it says: > 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 > to the MLD Querier in the IPv6 network. The MLD Querier (typically > acts as the PIMv6 Designated Router) 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. > > As is noted, the MLD querier and the DR may be different routers. > It is the DR and not the MLD Querier (if they are different) that > sends the PIM join. Also note that they are often different. If > there are two routers, then the one with the lowest address is the > MLD querier, while the one with the highest address (unless DR > priority is configured) is the DR. > > I understand your concern. I guess the Proxying spec solved this issue. > > > > Near the end of 4.2: > > A branch of the multicast distribution tree is then grafted, > comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 > part (from mAFTR downstream to the mB4). > > It says "is then grafted". So it sounds like the branch is added > to the tree after the procedure has finished. But basically it is > being added to the tree bit by bit as the joins are sent hop by > hop. Maybe it could say "is in this way grafted" or something. > I'm also a bit unsure whether "grafted" is a good term, as "graft" > has a specific meaning for PIM Dense Mode. > > Thanks for your suggestion, we'll reword it, and make it clarified. > > > > At the end of 4.2: > > The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so > as to represent the IPv4-embedded IPv6 source in the IPv6 multicast > network. > > Yes, probably in the IGP. Perhaps say more explicitly that there must > be a route due to PIM's use of RPF. I see this is mentioned in 7.1 > though. > > Ok. > > > > In 6.1 it talks about IGMP messages being translated to MLD. I would > argue that this is not necessarily how this would be done. > > Right, I agree with you. Please see my response to Simon, we can update the > text to clarify that. > > > If you look at a pure MLD proxy, you build state for various (*,G) > or (S,G) based on the reports you receive. Then based on this state > you create reports that you send upstream. It is not the message > from downstream that is just sent upstream. In this case, when > receiving downstream IGMP reports, they could be used to create the > IPv6 state. And then independent of whether the state was created > due to IGMP or MLD reports, reports are sent upstream, created from > that state. If you do this, messages are not translated. > > > In 7.1 it says: > > information to discover the source. In order to pass the Reverse > Path Forwarding (RPF) check, the IPv6 routers MUST enable PIM on the > interfaces which has the shortest path to the uPrefix64. > > Note that the shortest path might change due to topology changes, links > going down or coming up etc. So one would typically enable PIM on all > the routers. If one wants to constrain multicast to only some of the > topology, there are ways to build a separate multicast RIB for those > routers, and then enable PIM on all of them. > > The text just focuses on the special configuration, I understand your > concern that it's a little confusing. > Maybe we can add some text like "... as prerequisites, basic multicast > related configurations should be done accordingly ..." > > > > In 7.2 it says something about (*,G6) in mRIB6. The multicast RIB > is something different. I think it should say TIB. Check the terms > MRIB and TIB in RFC 4601. > > I'll check the terms again. > > > The draft assumes PIM-SM is used. I think the approach could also > be used with e.g. PIM Bidir (RFC 5015). > > Ok, we'll discuss this and come back to you on this point. > > > > 7.5 talks about scope, and mentions E and 8. Then it says that > this specification does not specify which scope to use. I would > perhaps not mention E and 8 then, it seems now to indicate that > those are the only alternatives. > > Fine. > > > > > The security considerations should probably be extended a bit. > E.g. what about scoping? Can one traverse a scoped boundary by > say joining a v4 scoped group using a join for a global v6 > prefix? > > Ok, we'll consider that. > > > > The draft should point out that it is just plain IPv4 in IPv6. At > least that seems to be the intention. However, one might use the > same solution with other tunnel types, e.g. GRE. > > We have a similar intention as the DS-Lite spec., we can some text. > > > Minor nits: > > Thanks, done. > > > o PIMv4: refers to PIM when deployed in an IPv4 infrastructure > (i.e., IPv4 transfer capabilities are used to exchange PIM > messages). > > o PIMv6: refers to PIM when deployed in an IPv6 infrastructure > (i.e., IPv6 transfer capabilities are used to exchange PIM > messages). > > Replace transfer with transport? > > Section 6.4 starts with this: > > If the mB4 function is implemented in the host which is directly > connected to an IPv6-only network. If an IPv4 application running in > > I'm not exactly sure what the first "if" refers to. This needs to be > reformulated. > > Also in 6.4 there is this typo: "implemntation". > > Stig > > > Thanks again for your careful review and comments. > > > Cheers, > Jacni > > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
