Re: [multrans] [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

[Tina TSOU <[e-mail]>]

Jacni,
Thank you for your prompt reply, which shows you are a very good engineer and coauthor.

You are too close to your text. You know what you want to say, but it doesn't necessarily say that to other people. A few of the observations below are of that nature.

Detailed replies below, marked with [TT].


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


From: Jacni Qin [mailto:[e-mail]]
Sent: Tuesday, August 23, 2011 7:32 AM
To: Tina TSOU
Cc: [e-mail]
Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04

Thanks for the comments, inline please.
On Tue, Aug 23, 2011 at 9:58 AM, Tina TSOU <[e-mail]<mailto:[e-mail]>> wrote:
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.
Jacni>: I don't see it, while you can post comments.
[TT] Where are the MUSTs, SHOULDs, and MAYs that have to be satisfied for interoperability? Everything is "will" or "should".


Section 1:

Editorial: at the end of the second paragraph, "vastly consumed" reads
better in English as: "consumed in vast quantities".
Jacni>: Sorry, EN is not my first language. Maybe we need the help from a native guy.
[TT] I'll get one to confirm this.

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."
Jacni>: No objection to add a sentence, but modified as "which preserves the efficiency of using multicast for traffics forwarding."
[TT] Why not the more specific statement? BTW, the word in English is "traffic". not "traffics".

Section 2:

Terminology: "Multicast AFTR" has connotations (IPv4 NAT) that simply
aren't there. Suggestion: "Multicast Transitional Border Gateway (mTBG)".
Jacni>: I think the AFTR is a general item, see the similar comments raised
in another thread about 4rd.

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:
Jacni>: Sorry, I don't agree. I think text in the paragraph following the bullet
explains the scope clearly.
[TT] The sentence that the text below omits reads as follows:

"While since technically, there is no extra function
    required for the scenario of native access (i.e. to access dual-stack
    content natively from the IPv6 receiver), this portion is not taken
    into account."

The title of the use case is: "An IPv4 receiver accessing IPv4 content (i.e., content formatted and reachable in IPv4)"

So what does an IPv6 receiver have to do with this? And getting content from the receiver? The whole sentence just doesn't make sense.

  "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."
Jacni>:That's what the current text means.
[TT] No, it just makes a case for it. We have to draw the conclusion, not leave it to the reader.

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 ..."

Jacni>: The signalling things will be detailed in the signalling section.
This is just a general description here.
[TT] The general description has to be general, not just focus on the handling of the multicast content.

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
Jacni>: Oops, got it, thank you.


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:
Jacni>: Actually, this is one of the typical cases.
The mAFTR can be embedded in the MLD Querier, which will
not bapass the IPv6 multicast infrastructure.
[TT] The only way I can see that is if the MLD Querier happens to have a link directly to the target IPv4 network, so traversal of the IPv6 network is unnecessary. Are you saying that providers will tend to arrange things this way?

"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.

Jacni>: We don't see the problems so far.
[TT] OK, taking out the opinion part, here is the comment: is that last paragraph talking about combining the mB4 and B4, the mAFTR and AFTR, or both possibilities? The text should make clear what we intend.

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.

Jacni>: Sorry, I don't understand the ".. IPv4 prefix that is shared by the source.."
For multicast routing, multicast routers including mAFTR will deal with that based on
converged unicast routing.
You can learn more about it in the following sections.
[TT] Well, this was a side issue, but are extra administrative arrangements needed to ensure that multicast signalling knows to go through the mAFTR rather than AFTR to reach the source, if both routers advertise reachability to the same IPv4 prefix?


No more comments up to section 7. Maybe more comments from section 7
onwards in a separate E-mail.
Jacni>: Thank again for your comments.


Cheers,
Jacni


Regards,
Tina
_______________________________________________
Softwires mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/softwires