Re: [Softwires] WGLC For draft-ietf-softwire-mesh-multicast - Please respond by 23rd March

[Ian Farrer <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires