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

From: Sérgio Figueiredo <[email-masked]>
Date: Tue, 06 Nov 2012 10:47:46 +0000

Dear authors,

I am aware of the concept of explicit tracking function for some time 
and wanted to check its status. As such I went through your draft and 
provide a more or less thorough review. I am sorry if am doing a lot of 
"noise", but I didn't find any details from previous ML discussions on 
the issues I address:

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.

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

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

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

"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".
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?
Q8 - How does the router's failed expectation that the sender is the 
sole member impact on the behaviour of other members?
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?
Q10 - Why is there no reference to Multicast Address Listener Interval 
(MALI) from MLDv2 RFC? Doesn't it impact your assumptions?

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

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

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?

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

Best regards,
Sérgio