Re: [Softwires] Work Group Last Call for draft-ietf-softwire-mesh-multicast-19 - Ends Jan 25th

[Ian Farrer <[e-mail]>]

Hi,

Please find attached my review of the draft.

Thanks,
Ian

---
Overall
IPv4-over-IPv6 and IPv4 over IPv6 (no spaces) are both used throughout. Likewise for IPv6-over-IPv4.
Please use one throughout (convention in other, published Softwire documents is IPv4-over-IPv6)

---
Abstract
The language of the Abstract is a little unclear and a bit messy. Here is a 
proposed re-write:

During the transition to IPv6, there will be scenarios where
a backbone network internally running one IP address family 
(referred to as the internal IP or I-IP family), connects  
client networks running another IP address family
(referred to as the external IP or E-IP family). In such
cases, the I-IP backbone needs to offer both unicast and
multicast transit services to the client E-IP networks.

This document describes a mechanism for supporting multicast
across backbone networks where the I-IP and E-IP protocol 
families differ. The document focuses on IPv4-over-IPv6 
scenario, due to lack of real-world use cases for IPv6-over-IPv4 
scenario.

---
1. Introduction
Para 1
If the above abstarct text proposal is acceptable, please replace paragraph 1
of the introduction with the first paragraph above.

---
Para 3.
"It is likely that client  E-IP multicast sources and receivers will
reside in different client E-IP networks connected to an I-IP backbone network.
This requires the client E-IP source-rooted or shared tree to traverse the I-IP
 backbone network."

This text seems redundant to me. The case for why the document exists
has been made in the previous paragraphs and cited RFC. E-IP traffic which
does not traverse the I-IP backbone is irrelevant to this document. I suggest 
that the sentances above are deleted and the remaining sentance (starting
with [RFC4925] outlines...) is moved to the end of paragraph 1 of the
Introduction.

---
Para 2
s/I-IP backbone, to efficiently/I-IP backbone to efficiently/

The paragraph is a single, very long sentance which makes it difficult
to understand. It would be easier to read with the following sentence break:

s/inside an I-IP core tree, which is rooted/inside an I-IP core tree. The I-IP tree is rooted/

---
Para 3
s/softwires mesh scenario/softwire mesh scenario/

---
Para 4
Suggested re-word of the first sentance (to avoid repetition of starting with 'One...')
This could be accomplished by re-using the multicast VPN approach outlined in [RFC6513].

---
s/Corporate enterprise networks and by extension multicast VPNs have been known/Corporate enterprise 
networks, and by extension multicast VPNs, have been known/

---
Para 5.
s/focuses on DS-lite [RFC6333]/focuses on the DS-lite [RFC6333]/

---
s/for IPv4-over-IPv6 softwire/for the IPv4-over-IPv6 softwire/

---
s/run IPv4 but the backbone/run IPv4 and the backbone/

---
Para 6.
s/somewhat different in that/somewhat different to the [RFC8114] scenario in that/

---
The sentence:
"Thus the need for a basic or closer alignment with E-IP and I-IP multicast procedures emerges."
could be more clearly worded. Suggested re-word:
Thus the need for alignment between the E-IP and I-IP multicast mechanisms emerges.

---
Para 7.
s/IPv6 can be achieved/IPv6 multicast can be achieved/

---
2. Terminology
This section is titled Terminology, but then starts with an overview of the problem. I suggest that the
first paragraph and diagram are moved to the Introduction and the definitions are left in the
Terminology section.

---
The AFBR defintion includes a MUST requirement. It is not usual to include such a requirement in 
a terminology definition. It would be better to have this requirement in the actual specification
section of the documenent (possibly a sub-section of 4.4). Also a MUST requirement to support 'functions
defined'. The requirment needs to be more specific about what these functions are, referencing the
specific sections of RFC5565.

---
I-IP and E-IP definitions - as only a 4over6 solution is actually described in the document, the 
IPv4 or IPv6 statement is confusing. The following form would be clearer (same change for E-IP):
I-IP (Internal IP): This refers to IP address family that is supported by the core network. In this
document, the I-IP is IPv6.

---
3, Scope
s/This document focuses on IPv4-over-IPv6 scenario, the following diagram shows the scenario./
This document focuses on the IPv4-over-IPv6 scenario, as shown in the following diagram:/

---
The diagram is quite messy and needs to be cleaned up (things are not properly aligned, etc.).
Possibly the attempt to draw clouds is a level of detail that does not render well in ASCII. It
might be clearer to just use boxes to represent the networks. Fig. 1 in RFC5565 would be a good
place to look for good example. Also, the AFBRs could be better shown, including their membership
(are they part of the IPv4 client networks, the IPv6 transit core, neither or both?)

---
The terms E-IPv4 and I-IPv6 are not in the definitions.

---
4.2 Group Address Mapping
"For the IPv4-over-IPv6 scenario, " - as the scope states that this is the only scenario that
the draft covers, it doesn't need to be repeated.

---
The figures in the draft are numbered 1,2 then 4. What happened to 3?

---
s/Figure 4 shows the reminder of the format:/Figure 4 is provided as a reminder of the format:/

---
4.3 Source Address Mapping
s/There are two kinds of multicast modes:/There are two kinds of multicast:/

---
o  E-IP network supports ASM
s/while the former is all cleared/while with the former, the bits are cleared/

---
s/(S'G')/(S',G')

---
Figure 5 is referenced, but there is no Figure 5.

---
The second time that the WC acronym is used, the Wildcard name is given. It would be better
to give the full name with the first use of the term earlier in the paragraph.

---
4.4 Routing Mechanism

"In the mesh multicast scenario, extra multicast routing information
is REQUIRED to be distributed among AFBRs to make sure that the PIMv6
messages that a downstream AFBR propagates reach the right upstream
AFBR.

Every AFBR MUST know the /32 prefix in "IPv4-Embedded IPv6 Virtual
Source Address Format".  To achieve this, every AFBR should announce
one of its E-IPv4 interfaces in the "v4" field, and the corresponding
uPrefix46.  The announcement..."

The above paragraphs are vague in what the requirements actually are. It Also
seems better to have the MUST requirement on the sending hosts behaviour so that this 
can be achieved rather than the receiving host. A suggested re-word:

"With mesh multicast, PIMv6 messages originating from a downstream
AFBR need to be propogated to the correct upstream AFBR, and every 
AFBR needs the /32 prefix in "IPv4-Embedded IPv6 Virtual
   Source Address Format". 

To achieve this, every AFBR MUST announce the 
address of one of its E-IPv4 interfaces in the "v4" field alongside
the corresponding uPreifx64. The announcement..."

---
The '/32 prefix' term that is used here is unclear. I assume that
it is referring to the Group Address located in bits 96-127 of Fig 4.
This isn't really a prefix in this context. Please clarify.

---
Para 2.
...and uniquely identifies each AFBR.
Surely it uniquely identifies each AFBR interface?

---
s/But "v4" field/But as the "v4" field/

---
Early in the paragraph, there is a SHOULD requirement to send BGP messages
over MBGP, but later in the paragraph there is a MUST requirement for sending
BGP over IPv6. Is this intentional? Can this work without MBGP?

---
A paragraph break after "...back to (S,G)." would help with readability.

---
s/with "source address"/with the "source address"/

---
"...field set to *(the IPv4 address...". What is meant by this?

---
5.2 E-IP (*,G) and (S,G) State Maintenance

s/on AFBR is the same as E-IP (*,G) and (S,G) state maintenance on
mAFTR/for an AFBR is the same as E-IP (*,G) and (S,G) state maintenance for an mAFTR/

---
5.4.  Inter-AFBR Signaling

Para 1.
s/decide/decided/

---
s/towards RP./towards the RP./

---
s/data of (S,G)./data for (S,G)./

---
Para 2.
s/a (S,G,rpt)/an (S,G,rpt)/

---
Para 5.
s/multicast data of (S,G)/multicast data for (S,G)/

---
The sentance:
"along the RPT received by SPT-switched-over downstream AFBRs"
Is not very clear. Suggest the following re-word:
"along the RPT received by AFBRs affected by the SPT switch over"

---
Figure 7 is incorrectly numbered.

---
Para 7.
s/example of interface agent/example of an interface agent/

---
Para 8.
s/machines of every downstream AFBR/machines for every downstream AFBR/

---
s/is at Prune(P)/is in the Prune(P)/

---
s/data of (S,G) along/data for (S,G) along/

---
Para 10.
"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 be preserved."

Is the word 'that' in "...neighbor of RP' that has joined..." needed 
here?

---
5.5.  SPT Switchover
Para 1.
"...in spite of whether they have switched over to an SPT of some source(s) or not."
What is meant by 'some source' in this sentence?

---
7.  Packet Format and Translation
Para 1.
s/ when traversing AFBR./ when traversing an AFBR./

---
Para 2.
s/in IPv4 and IPv6 address family./in the IPv4 and IPv6 address families./

---
Para 3. 
"In Figure 8, the semantics of fields "PIM Ver", "Type", "Reserved",
   and "Checksum" remain the same."
What do they remain the same as?



> On 11. Jan 2018, at 14:03, Ian Farrer <[e-mail]> wrote:
> 
> Hi,
> 
> The authors believe that draft-ietf-softwire-mesh-multicast-19 is now ready for advancement. This email marks the start of a 2 week work group last call for the draft.
> 
> Please send your comments, either for or against, to the softwire WG mailing list. The WGLC will end on Jan. 25, 2018.
> Thanks,
> Yong & Ian
> 
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires