Hi all,
In IETF-81, the chairs asked the authors of different drafts on multicast sit
together to discuss and compromise. So we did.
Here are some comments on draft-qin-softwire-dslite-multicast-04.
Overall: if this is to be a Standards Track document, the whole document
has to be reviewed, the normative parts identified, and requirements
language substituted for the current descriptive language.
Section 1:
Editorial: at the end of the second paragraph, "vastly consumed" reads
better in English as: "consumed in vast quantities".
Substantive: add the following to the sentence making up the third
paragraph:
"..., which prevents these consequences by making use of the native
multicast capabilities of the intervening IPv6 network."
Section 2:
Terminology: "Multicast AFTR" has connotations (IPv4 NAT) that simply
aren't there. Suggestion: "Multicast Transitional Border Gateway (mTBG)".
Substantive(?): In the description of the Multicast B4, it would make
more sense to change "... which is able to enforce ..." to "... which
implements ...".
Section 3.2:
Bullet 1: the second sentence jams two unrelated ideas together. It
needs a little expansion to read properly. The next sentence doesn't
make sense within the stated scope of the bullet and shouldn't be there.
The suggested changed text is thus:
"A viable scenario for this use case in DS-Lite environment: customers
with legacy receivers must continue to access the IPv4-enabled
multicast services. This means the traffic should be accessed
through IPv4 and additional functions are needed to traverse the
operator's IPv6- enabled network. It is the purpose of this
document to describe those functions. Refer to [I-D.jaclee-behave-
v4v6-mcast-ps] for the deployment considerations."
Final paragraph: don't you need a final sentence saying something like:
"Depending on the specific details of the contract, this may mean that
the specific framing of the content packets (as IPv4 packets) must be
preserved along with the content within that framing."
Section 4:
First paragraph: the following sentences need to be added after the
first one to give a full picture of what is required for a solution:
"For multicast, in contrast, separate mechanisms are required to process
the outgoing multicast signalling packets and the incoming packets of
content. The multicast signalling needs to be interworked to IPv6 and
processed as IPv6 signalling. For incoming multicast content, this
document defines ..."
Middle paragraph: why doesn't it simply read:
"See Section 4.3 for multicast distribution tree establishment and
Section 4.4 for multicast traffic forwarding."
Section 4.2
Third paragraph typo: mPrefixe64 -> mPrefix64
Section 4.3
Bullets: it makes no sense to embed the mAFTR in the MLD Querier. That
would cause the native IPv6 multicast infrastructure to be bypassed. It
is also inconsistent with the architectural figure. Delete the first
bullet and merge the second one with the next paragraph, like this:
"The mAFTR should process the received PIMv6 Join message for the
IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join
message. It creates an entry for the IPv6 multicast group address in its
multicast Routing Information Base. This entry is used to forward ..."
Section 4.5
It is not clear whether the final paragraph is talking about the mB4+B4
or the mAFTR+AFTR or both. In fact, it makes good sense to combine the
mB4 and the B4, but combining the AFTR and mAFTR would be questionable
for reasons of scalability. There may be routing issues to sort out
regarding reachability of the IPv4 prefix that is shared by the source
-- the multicast routers should choose the path leading through the
mAFTR rather than the one going through the AFTR.
No more comments up to section 7. Maybe more comments from section 7
onwards in a separate E-mail.
Regards,
Tina
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
