Dear Ian, We just posted a new version (draft-ietf-softwire-mesh-multicast-17.txt ). The following text is responds to the questions raised recently.
Q1： In light of the above, I think that reducing the scope to IPv4 in IPv6 only may be a good idea. Answer: According to IAB statement on IPv6 https://www.iab.org/2016/11/07/iab-statement-on-ipv6/, IAB expects that the IETF will stop requiring IPv4 compatibility in new or extended protocols. draft-ietf-softwire-mesh-multicast considers both IPv4-over-IPv6 and IPv6-over-IPv4 scenarios. Since we cann't see any real users in IPv6-over-IPv4 solution, we reduce the scope to IPv4-over-IPv6 only. Q2：Instead of (re)specifying the behavior it would be more appropriate to refer to draft-ietf-softwire-dslite-multicast (RFC8114) when it makes sense (e.g., AFBR behavior, address mapping, CP, DP, etc.). The document says the following: The mPrefix46 for SSM mode is also defined in Section 4.1 of [RFC7371]. This is not true. RFC7371 is about flag bits not MPREFIX64. Instead of referring to RFC7371, adding a pointer to Section 5 of draft-ietf-softwire-dslite-multicast would make sense. Answer: We refer to RFC8114 in section 4.2, and add a pointer to Section 5 of draft-ietf-softwire-dslite-multicast when defining mPrefix46 for SSM mode. Q3: 4. Mechanism Overview "When the I-IPv6 PIM message arrives at the upstream AFBR, it MUST be translated back into an E-IPv4 PIM message." As this is in the overview, it doesn't seem the right place to specify the MUST behavior. Section 5 covers this in detail. Suggest replacing MUST with 'is'. Answer: In the latest version, we have replaced ‘MUST’ with ‘is’. Q4: 5.5 Inter-AFBR Signaling This section states that an RP' SHOULD NOT process messages on it's incoming interface, by introducing an interface agent. However, at this point the text becomes vague as to whether it is mandatory to have an interface agent implementation. If you are saying that you should not do something then it would follow there needs to be an equivalent statement of what you should do instead. Also the functionality of the interface agent is only described as how it MAY work. This also seems vague. It would be better to describe what the behavior is with RFC2119 language, and then state something along the lines of 'the mechanism used to achieve this is left to the implementation, the following diagram provides a possible solution', or words to that effect. Answer: We use the word ‘SHOULD’ because there may exist valid reasons in particular circumstances (when there is only one downstream router) to ignore the implementation. In the lastest version, we added an equivalent statement of what we should do instead as following: RP’ SHOULD prune S from the RPT of group G when no downstream AFBR is subscribed to receive multicast data of (S,G) along the RPT. In the latest version, we edited the sentence as following: The mechanism used to achieve this is left to the implementation, the following diagram provides a possible solution that "interface agent" MAY be implemented. Q5: 6.2 Selecting a Tunneling Technology "some AFBRs SHALL not" - The RFC2119 'SHALL' isn't really necessary to describe how the mechanism is required to fail if a requirement isn't met. 'will' would be a better word to describe the effects. Sections 6.2 and Section 8 seem to be repetitions. Suggest that they are combined into a single section. Answer: We deleted Section 6.2. Q6: Language/Grammar Answer: We re-checked the language and grammar again throughly. Q7: 'the preferred solution' is probably not the best choice of words here. As there are other options being written, someone else prefers something else. 'One solution is to' might be a better choice. Answer: We have changed it to “One solution is to”. Q8: The sentance "This scenario is ..." is redundant as it is clear from context and the figure name. Suggest it is removed (same comment applies to other figures) Answer: We have removed the sentence. Q9: Suggest that the second sentance is replaced with: "These networks support native IPv6 services and applications but in many cases, support for legacy IPv4 unicast and multicast services will also need to be accomodated." Answer: We have replaced it. Q10: For clarity, it would be worth describing how the scoping of IPv6 will resolve the problem. Answer: Thank you for your kindful comments. We added the words that describe it: “such as applying a "Well-Known" prefix or an ISP-defined prefix." Q11: "Through the set of known and deployed mechanisms". This is (intentionally, I expect) quite vague. It might help to give an example or two of a suitable mechanism to use. Also, "Through the set of..." could be reworded as "Using an existing mechanism" Answer: We reword it as “through the PIM messages”. Q12: The above would be much easier to read formatted as a list. Answer: We have formatted it as a list. Q13: There's quite a lot of important information in the above paragraph, but it's difficult to parse with the current wording. Suggest that it's reworded for clarity. Answer: We have reworded it for clarity. Q14: would "translated message will eventually arrive at" be better worded as "translated message can be forwarded to" Answer: We have reworded it in both this section and the next section. Q15: The same comments for the Routing Mechanism section above are also relevant to this section. Please also apply here. Answer: In this section, we have applied the comments of the previous section. Q16: unclear what is meant by "SHOULD NOT be used otherwise" Is the intention to say that the well-known prefix is used solely for this purpose? Please clarify. Answer: For clarity, we have re-edited the sentence as following,“Since the translated source address starts with the unique "Well-Known" prefix or the ISP-defined prefix that SHOULD NOT be used by other service provider" Q17: Would 'do not process' be better wording than 'not supposed to understand'? Answer: Thank you for the suggestion, we have reworded it. Q18: Would 'wants to receive' be better worded as 'is subscribed to receieve'? Answer: Thank you for the suggestion, we have reworded it. Q19: The above needs some rewording to remove the terms 'the AFBR wants' and 'downstream AFBR has changed its mind'. These terms imply a level of free will that routers don't posess! Answer: We changed ‘the AFBR wants’ to ‘the AFBR is subscribed to’. We changed ‘downstream AFBR has changed its mind’ to ‘’downstream AFBR switched to’. Q20: I'm not sure what 'SHOULD still take effect' is meant to mean in this context. Answer: We have reworded it as ‘SHOULD keep alive’. Q21: Suggest 'expresses its interest' is replaced with a less anthromorpic term. Answer: Thank you for your suggestion. Because the term is used in RFC 4601, we also used it in this documents. Q22: In the above, is 'forward to the outgoing interface' the correct term? Doesn't it forward via the outgoing interface, or send from the outgoing interface? Answer: We have re-edited the words. Q23: Is the language strong enough here? 'some AFBRs may not' - If two AFBRs are not using the same tunnelling technology, it will not work. 'may' suggests there's a chance that it will. Answer: We changed ‘may’ to ‘SHALL’. Q24: Should fragmentation be performed before or after encapsulation, or doesn't it matter? Fragmentation should be performed after encapsulation as in RFC 5565. Answer: We have re-edited this section. Q25: This section differs from the guidance in the section "Selecting a Tunneling Technology" above. Answer: In the section “Selection a Tunneling Technology”, we re-edited the text as following, "It is REQUIRED that all AFBRs use the same technology”, so both section express the same meaning. Q26: This section could be made more clear by structuring as: The security concerns raised in RFC4925 and RFC7761 are applicable here. In addition, the additional workload associated with some schemes... Answer: Thank you for your suggestion, we have re-edited this section. Q27: This section needs work. If a global prefix is being requested, then it needs to be clearly stated (what is being requested, what it will be used for, how it needs to be registered). If not, then there should be nothing here. Answer: Thank you for your comments. We have changed the section to "This document includes no request to IANA.”. Mingwei 2017-08-04 Mingwei Xu 发件人： Ian Farrer 发送时间： 2017-07-26 16:37:31 收件人： xmw 抄送： yong 主题： Fwd: [Softwires] ask for WGLC Hi Mingwei, I’m forwarding this as it got bounced. Hopefully you’ll get it this time. Thanks, Ian Begin forwarded message: From: Ian Farrer <[email protected]> Subject: Re: [Softwires] ask for WGLC Date: 26. July 2017 at 10:16:18 GMT+2 To: [email protected] Cc: Softwires list <[email protected]> Hi Mingwei, Thank you for your email. Checking the comments that were received during the last WGLC, there is: https://mailarchive.ietf.org/arch/msg/softwires/LT2ttfqUXw4IjwGFFBBrPMayoiU Please could you respond to the questions it raises, particularly point 1. Thanks, Ian On 26. Jul 2017, at 09:27, Mingwei Xu <[email protected]> wrote: Hi, Chairs, The draft of softwire mesh multicast was first proposed in September 2011 and updated 15 times. We think the draft is mature and it is ready for the last call. The recent revision history is as following: 2017 Apr 1. We updated the 16th version according to Med’s advice. 2017 Jan 10. We updated the 15th version according to IAB statement on IPv6 <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>, where IAB expects that the IETF will stop requiring IPv4 compatibility in new or extended protocols. 2016 Nov 13. We updated the 14th version according to Ian’s advices. 2016 May 24. We asked for WGLC in the working group. 2016 May 22. We updated the 13th version, where we revised the language and grammar throughout. 2016 Feb 4. We updated the 11th version, where we updated the security consideration. Best regards, Mingwei -------------- Mingwei Xu 2017-07-26 _______________________________________________ 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
