Hi, Here is my review of the draft.
Cheers, Ian Technical/General Comments 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'. 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. 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. Language/Grammar Abstract - Prosed re-word for readability: The Internet needs to support IPv4 and IPv6 packets. Both address families and their related protocol suites support multicast of the single-source and any-source varieties. During the transition to IPv6, there will be scenarios where a backbone network running one IP address family internally (referred to as the Internal IP or I-IP) will provide transit services to client networks running another IP address family (referred to as the External IP or E-IP). It is expected that the I-IP backbone will offer unicast and multicast transit services to the client E-IP networks. Softwire Mesh is a solution that provides E-IP unicast and multicast support across an I-IP backbone. This document describes a mechanism for supporting Internet-style multicast across a set of E-IP and I-IP networks supporting softwire mesh. We focus on the IPv4- over-IPv6 scenario in this document, due to lack of real-world use cases for the IPv6-over-IPv4 scenario. Section 1 Suggest '..one or more ingress AFBR' is replaced with '..one or more Address Family Border Router (AFBR)' for clarity. Last sentence, last paragraph: "We focus on IPv4-over-IPv6 scenario in this document, due to lack of real-world use cases for IPv6-over-IPv4 scenario." Suggest this is deleted as it is a repetition from the abstract. 2. Terminology Replace o Upstream AFBR: The AFBR router... o Downstream AFBR: The AFBR router... With o Upstream AFBR: An AFBR router... o Downstream AFBR: An AFBR router... 3. Scenarios of Interest This document focus on IPv4-over-IPv6 scenario, however, the following mechanism offers a reference for IPv6-over-IPv4 scenario if needed. This is confusing, as what follows is a diagram of 4over6 mesh m/c. Is it left in from a previous version of the draft? 4.3 Source Address Mapping Replace Considering that I-IP network... With Considering that the I-IP network... 5.5 Inter-AFBR Signalling Replace "and decide to perform a SPT switchover" with "and decides to perform an SPT switchover" 5.6 SPT Switchover "After a new AFBR expresses its interest in receiving traffic..." sounds a little anthropomorphic to me:-) Would "After a new AFBR requests the receipt of traffic..." be better? "...thus no more redundancy will be produced." Is redundancy the right word here? Would 'unnecessary duplication' be better? 5.7 Other PIM Message Types Replace 'Apart from Join or Prune...' With 'In addition to Join and Prune...'' 6.2 Selecting a Tunneling Technology Replace 'Choosing tunneling technology' with 'Choosing a tunneling technology' 6.3 TTL Suggest 'Processing of TTL' is changed to 'Processing of TTL information in protocol headers' or similar for clarity. Figure 7 Text This paragraph is quite long and dense and so is difficult to follow. Suggest that it's broken into shorter paragraphs, or possibly number the diagram and then have the text as a corresponding numbered list. > On 09 Mar 2017, at 17:21, Ian Farrer <ianfar...@gmx.com> wrote: > > Hi, > > The authors of draft-ietf-softwire-mesh-multicast-15 believe this document is > ready for advancement. We would like to issue a two week working group last > call finishing on 23rd March. > > Please send any substantive comments to the list and express your opinion on > whether this draft is ready for publication. You are also welcome to send > your editorial comments directly to the authors. > > Thanks, > Yong & Ian > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires