+1 On 6/12/12 4:46 PM, "Stig Venaas" <[email protected]> wrote:
>On 6/12/2012 1:11 PM, Behcet Sarikaya wrote: >> 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. > >What do you mean by making it specific to DS-Lite? Are you talking >about a different technical solution, or just wording? Right now the >technical solution is generic, and I think that is great. While the >wording seems DS-Lite specific to me. > >I don't like the idea of doing something DS-Lite specific, unless one >can come up with a better technical solution that way. > >I think the technical solution in this draft is fine. Please let's not >change it into a poor technical solution just to satisfy possible >charter considerations. > >Stig > >> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
