Subject: Re: [pim] I-D Action: draft-ietf-pim-explicit-tracking-02.txt

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 11 Dec 2012 15:00:00 +0900 (JST)

Hi Sérgio,

Thank you for your comments. I also found several editorial
ambiguities and duplicate sentenses inside the previous draft.
I've just submitted the revised draft. Please read it.

I also write some comments below.

> Section 1:
> "This function implements the following requirements (... ) where this
> document mainly focuses on the above second and third bullets in the
> following sections."
> Q1 - It seems the described list mixes features with
> requirements. Alternatively, if these are in fact requirements, I
> don't think it is acceptable that only 2 of them are described, at
> least not with justifying why the others are negligible.

Ok, we change the statement to "This function enables the following"
and remove "where this document mainly focuses on the above first and
second bullets in the following sections" as it's not a necessary
message for this specification.

> Section 2:
> - The organization of Section 2 could be improved, or at least an
> - introduction for what is described within it should be placed;
> 
> Section 2.1
> "This mechanism is called "specific query surpression mechanism."
> Q2 - It seems that what you refer to as a mechanism is more of an
> advantage of the explicit tracking function itself: i.e. reduction of
> number of group / channel specific Query messages plus Current-State
> Report messages). Also, it should be corrected it to "suppression".

Ok, we can eliminate the word, "mechanism", so now it is smiply
"specific query suppression".

> "If a router enables the explicit tracking function, it does not need
> to always ask Current-State Report message transmission to the member
> hosts whenever it receives the State- Change Report."
> Q3 - Do you mean it does not send a group or channel specific Query by
> default whenever it receives the State-Change Report"?

No. The router sends a specific query as the default.

> Q4 - Why is it stated "it does not need to"? Is a decision involved
> and when does it apply? Which one and based on what information?

Specific queries are used to confirm whether the State-Change report
sender is the sole member of that session/channel or not. But a router
turning on the explicit tracking function can expect the report sender
is the sole member or not. So, it does not need to do so.

Anyway I've changed the corresponding statement a little as follows;
"If a router enables the explicit tracking function with "specific
query suppression", it suppresses specific query transmission and
transmits specific query messages only when the router expects that
the State-Change Report sender is the sole member of the channel,
based on its membership state information."

When it applies?
It applies when a router enables the explicit tracking function and specific
query suppression.

> "This is because the explicit tracking function works with the
> expectation that the State-Change Report sender is the last remaining
> member of the channel."
> Q5 - I am sorry but I am puzzled by this sentence. Shouldn't this be
> only assumed after checking whether the list of "receiver records" for
> a group / channel is limited to one member?

When the router expects the report sender is the sole member.

> "Even if this expectation is wrong (i.e., the State-Change Report
> sender was not the sole member), other members remaining in the same
> channel will reply with identical Report messages, so the end result
> is the same and no problem occurs. (Section 3
> <http://tools.ietf.org/html/draft-ietf-pim-explicit-tracking-02#section-3>
> details the point.)"
> Q6 - reading this sentence makes me realize that probably the word
> "assumption" should be used instead of "expectation".

I believe "expectation" is better. Because existance of remaining
active members is not assumed, but expected.

> Q7 - related to the previous point, I can't understand why the router
> always expects this, disregarding the membership records for which the
> Explicit Tracking Function is introduced. More concerning is that I
> can't find any justification or correlation to this on section
> 3. Should it be Section 2.3?

Section 4 in the revised draft clarifies it.

> Q8 - How does the router's failed expectation that the sender is the
> sole member impact on the behaviour of other members?

Section 4 explains it.

> Q9 - What do you mean by "identical Report messages"? If you're
> talking about State-Change Reports, why would these other interested
> members send State-Change Reports if they're still subscribing the
> group / channel? How is it assured that the multicast router doesn't
> remove a state for a group / channel being received by other
> members?

It is standard behavior defined in rfc3376 and 3810.

> Q10 - Why is there no reference to Multicast Address Listener Interval
> (MALI) from MLDv2 RFC? Doesn't it impact your assumptions?

MALI does not impact fast leave. Fast leave is realized by tuning
LMQI/LLQI and LMQC/LLQC (and hence LMQT/LLQT).

> "When the querier surpresses the specific query message transmission,
> if it recognizes that the State-Change Report sender is not the sole
> member of the channel, (...)"
> Q11 - How does it recognize the Report sender is not the sole member
> of the channel It is stated several times that it expects the mobile
> host to be the last member so in which cases is this verified
> against?

Routers enabling the function maintain the "membership state
information". By referring the membership state information, they can
expect the report sender is the sole member of the channel or
not. Whether the report sender is a mobile host or not is not
important.

> When reading the document it seems that the router expects any
> State-Change Report sender to be the last member of a
> subscription. Just to be sure, is this correct or am I missing
> something?

The membership state information consists of (S, G, number of
receivers, (receiver records)). Routers maintain this record and
expect who are now active and whether the state-change report sender
is the sole member or not.

> "he [Last Member Query Interval] (LMQI) and [Last Listener Query
> Interval] (LLQI) values specify the maximum time allowed before
> sending a responding Report."
> Q12 - It should be corrected to "(...) before sending a responding
> Query".

No. "... before sending a responding Report" is correct.

> Section 2.3
> "IGMP/MLD messages are non-reliable and may be lost in the
> transmission, therefore routers need to confirm the membership by
> sending Query messages"
> Q13 - does the text refer to General Queries only?

No, this "Query messages" means any kinds of query messages.

> Overall, my impression is that the default operation (as well as any
> operation option) of the multicast router should be clearer.

Thanks. I believe the revised one clearly mentioned it.

Regards,
--
Hitoshi Asaeda

---

From: Sérgio Figueiredo <[email-masked]>
Date: Fri, 21 Dec 2012 17:45:40 +0000

Hi Hitoshi,

Thank you for the detailed answers and clarifications, and for taking 
into account all my comments. Please refer to my answers below.

> message for this specification.
SF: Ok.
> "specific query suppression".
SF: Ok. Now that it is much clearer to me, I see no problem with the 
usage of "mechanism". What was not clear before was that "specific query 
suppression" was something that could be enabled / activated when using 
Explicit tracking function for the goal of achieving better efficiency; 
on the other hand Explicit tracking can be used for per-host accounting 
or other functions which are independent of this suppression mechanism.
> No. The router sends a specific query as the default.
SF: Ok, I see you improved the text significantly, good to see.
> It applies when a router enables the explicit tracking function and specific
SF: Ok. Again, now it is more clear to me in which cases specific query 
suppression may not be activated.
> When the router expects the report sender is the sole member.
SF: Ok, understood from previous text.
> active members is not assumed, but expected.
SF: Ok, clarified.
> Section 4 in the revised draft clarifies it.
SF: Cleared, most issues were in fact related :)
>> sole member impact on the behaviour of other members?
SF: Ok.
> It is standard behavior defined in rfc3376 and 3810.
Sure, but my point is, if you activate the suppression mechanism, no 
query will be sent in case the router expects the report sender to be 
the sole member of the subscription. Consequently, the other receivers 
will not send "identical report messages". Anyway, I see you removed 
this from current text so it's ok now.
> LMQI/LLQI and LMQC/LLQC (and hence LMQT/LLQT).
SF: Ok.
> not. Whether the report sender is a mobile host or not is not
SF: Ok.
> is the sole member or not.
SF: Ok.
> No. "... before sending a responding Report" is correct.
SF: The usage of "before sending a responding Report" leads to the 
notion that we're referring to the router side. I would suggest that you 
explicitly state "allowed for a subscription member to send a responding 
Report before the router prunes the group or sources from the network".
> No, this "Query messages" means any kinds of query messages.

SF: Ok, thank you.

Additionally, I have one more suggestion:
- In section 1, when it is stated "To resolve the problem", I think that 
"To alleviate the problem" would fit better. The reason for this is that 
in case of a lost "report", there are still lost data packets during the 
interval between the lost IGMP/MLD Report and the next General Query.
- correct small typo in section 1: "may not reached" ->  "reach".

Best regards,
Sérgio