Hi, Ian, Thank you very much for your comments. We have updated our draft according to your comments, and published as draft-ietf-softwire-mesh-multicast-18.
Please see inline the reply for your comments. Best regards, Mingwei 2017-09-25 Mingwei Xu 发件人： Ian Farrer 发送时间： 2017-09-18 16:39:23 收件人： Softwires list; draft-ietf-softwire-mesh-multicast 抄送： 主题： Re: [Softwires] Review of draft-ietf-softwire-mesh-multicast-17 I had to forward this to the list separately as the original message was too large. I’ve removed any points which have been resolved. Cheers, Ian ------ Hi Mingwei, Please see inline below. One additional comment that I found from reading —17: Section 4.4 - This states that the the AFBR MUST implement route redistribution for IPv4 multicast in BGP. As I read it, this means that the AFBR must implement RFC4760. Is this correct? If so, a normative reference is needed. Reply: We added a normative reference in the latest version. Best regards, Ian On 4. Aug 2017, at 10:43, Mingwei Xu <[email protected]> wrote: 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. 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.). [if - The original comment (as I understand it - it was raised by Med) is that there are a number of similarities between what is described in this draft and RFC8114 in the relevant sections. Rather than re-specifying what is in RFC8114, a comparison needs to be made between the two documents. Where behaviour is already specified in RFC8114, softwire-mesh multicast should reference it. Where it differs, describe the differences. One example I found from a cursory comparison: The AFBR data plane behaviour described in Section 6.1. The text here is currently quite unclear - especially the use of encapsulate/decapsulate (e.g. could be construed that a v6 packet gets encapsulated in v4). Does this data plane behaviour differ from RFC8114 Sec 7.4? If not, a reference would be better. If it is different, then the text needs to be cleared up and describe the differences. ] 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. [if - This also refers to the above comment. The mPrefix64 addressing format is given in Section 5 of RFC8114. The text in section mesh-multicast 4.2 has a pointer to section 2 of RFC8114. Note that RFC8114 is defining mPrefix64, not mPrefix46. Suggest that the line The mPrefix46 for SSM mode is also defined in Section 2 of [RFC8114]. Is replaced with: The construction of the mPrefix46 for SSM is the same as the construction of the mPrefix64 described in Section 5 of [RFC8114]. ] Reply: In the latest version, we made comparison with RFC8114 and re-edit Section 4.2, Section 5 and Section 6.1. 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. [if- OK, but the resulting text has become quite complicated. What about the following re-wording, including text for the exception to the SHOULD? To solve this problem, we introduce an "interface agent" to process all the encapsulated (S,G,rpt) messages the upstream AFBR receives. The interface agent's 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 this way, we ensure that downstream AFBRs will not miss any multicast data that they need. The cost of this is that multicast data of (S,G) will be duplicated along the RPT received by SPT-switched-over downstream AFBRs, if at least one downstream AFBR exists that has not yet sent Prune(S,G,rpt) messages to the upstream AFBR. In certain deployment scenario’s (e.g. if there is only a single downstream router), the interface agent function is not required. The mechanism used to achieve this is left to the implementation. The following diagram provides one possible solution for an "interface agent" implementation: ] Reply: Thank you for your suggestions, we have already changed the words in the latest version. 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’. [if - The resulting text is not very clear: NOTICE: It is possible that an E-IP neighbor of RP' that has joined the RPT of G, so the per-interface state machine for receiving E-IP Join/Prune (S,G,rpt) messages SHOULD keep alive. The text reads that the state machine process should 'keep alive’ (not crash?). I guess that the intended meaning is that the current state in the state machine should be preserved.] Reply: We change the sentence to: It is possible that an E-IP neighbor of RP' that has joined the RPT of G, so the per-interface state machine for receiving E-IP Join/Prune (S,G,rpt) messages SHOULD be preserved. 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. [if - Just checked RFC4601, yes it makes sense to use consistent terminology] 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’. [if - This answer seems to be related to the now defunct Section 6.2. The current wording of Section 8 is OK] 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. [if - ? In this version, only Section 8 deals with this. I think the current text is OK here.] Mingwei
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
