Subject: Re: [pim] draft-ietf-pim-explicit-tracking pim 3rd wglc

From: Hitoshi Asaeda <[email-masked]>
Date: Sun, 06 Oct 2013 18:50:50 +0900 (JST)

Hi Bharat,

Thank you for your detail comments, and sorry for my late response.
I'll submit -08 tomorrow, but before it, I reply for your mail.

> * In Introduction, in following sentence:
> 
>    Also, a querier router periodically sends IGMP/MLD General Query
>    messages within the General Query timer interval (i.e. [Query
>    Interval] value defined in [2][3]).
> 
> Should we use 'every' instead of 'within the'? It will become:
> 
>    Also, a querier router periodically sends IGMP/MLD General Query
>    messages every General Query timer interval (i.e. [Query
>    Interval] value defined in [2][3]).

Done.

> * In Introduction, in following sentence:
> 
>    IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can
>    provide the ability to keep track of the downstream (adjacent)
>    multicast membership state to multicast routers, yet the
>    specifications are not clearly given. 
> 
> Should we use 'in mulicast routers' instead of 'to multicast routers'. It will become:
> 
>    IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can
>    provide the ability to keep track of the downstream (adjacent)
>    multicast membership state in multicast routers, yet the
>    specifications are not clearly given. 

Done.

> * In Introduction, in following sentence:
> 
>    Particularly when a router needs to maintain a large number of
>    member hosts, this resource requirement could have an impact. 
> 
> Can we elaborate a little on the 'impact' we are referring here? What kind of impact? Is it impact on router functionality or something else?

I changed to "might be sensitive".

> * In section 3, the draft describes the new multicast membership
> state information a multicast router conforming to this draft
> creates. For implementors, should not this draft also mention when
> or under what conditions to remove this membership state?

I added;
"The router will flush the maintained membership state information
when it reboots or restarts the multicast routing processes."

> * In section 4, in following sentence:
> 
>    All member hosts joining the identical
>    channel then reply their own states after acquiring these query
>    messages. 
> 
> Will it be better to add a 'with' between 'reply' and 'their'? It will become:
> 
>    All member hosts joining the identical
>    channel then reply with their own states after acquiring these query
>    messages. 

Done.

> * In section 4, in second para, it is exaplained that if router
> receives one or more replies from the downstream members, it can
> stop retransmitting the specific query message. In my understanding,
> this should be reworeded to say that the groups or sources for which
> downstream members exist, should not be included in subsequent
> specific query messages. If there is no such group or source
> available, router can stop sending specific query message.

I added "for the specified source and/or group" at the last part of
that sentence such as:
"... it can stop (i.e., cancel) retransmitting the specific query
message(s) for the specified source and/or group."

> * In section 4, in last para, in following sentence:
> 
>    For the latter
>    case, when the querier suppresses the specific query message
>    transmission, and expects that the State-Change Report sender is not
>    the sole member of the channel, it does not send the specific query
>    and none of the routers on the same LAN receive a Current-State
>    Report message from the corresponding member hosts. 
> 
> This sentence is too big and is not clear enough. Can we please divide this into multiple sentences?

I split into two sentences.

> * In section 5, in para 4 :
> 
>    Furthermore, if operators believe that their link is fairly robust or
>    that they can configure the [Robustness Variable] value appropriately
>    so that the chances of unsolicited messages being lost are
>    sufficiently low, and if the querier router is always the forwarder
>    router in their link, they will set smaller LMQC/LLQC and shorter
>    LMQI/LLQI (and hence shorter LMQT/LLQT) with the specific query
>    suppression or enable the specific query suppression in a robust link
>    state (Section 4) for their routers.
> 
> This whole para is one single sentence. Someone reading it may be
> lost. So in my opinion, it is better to divide this into multiple
> sentences.

I use "()" for sentence to be omitted. If you skip "()" parts, it will
be;

"Furthermore, if operators are confident that their link is fairly
robust, and if the querier router always acts as the forwarder router
for all mutlicast channels in the LAN, they will set smaller LMQC/LLQC
and shorter LMQI/LLQI with the specific query suppression, or enable
the specific query suppression in a robust link state (Section 4) for
their routers."

It is readable?

> Another suggestion is that we do not really need the part "and if
> the querier router is always the forwarder router in their link," in
> this sentence. I am not sure why is this required here?

It is explained in Sect.4 as follows;
"when the querier suppresses the specific query message transmission,
and expects that the State-Change Report sender is not the sole member
of the channel, it does not send the specific query. Then the routers
(including the forwarder) on the same LAN do not receive a
Current-State Report message from the corresponding member hosts. The
forwarder in this case may prune the routing path, although there are
other member hosts subscribing to the channel on the LAN."
(This sentense is a little modified from -07.)

> * In Security consideration, do you think it will be good to mention
> about 'IPSec' usage for IGMP/MLD messages as well?

I don't think so. It needs enough consideration, which is out of
scope of this document.
(Relying on IPsec is not always happy for every situation, IMO.)

Regards,
--
Hitoshi Asaeda

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 7 Oct 2013 02:51:07 +0000

Hitoshi,

       Thanks for taking care of my comments. I have some replies inline with 'Bharat>'

Regards,
Bharat Joshi
http://bite-the-bytes.blogspot.com/

Bharat> If we are saying that it could have an impact or it might be sensitive, I think we should also say in what respect? This will give a beter idea for an implementor. Please ask others in the mailing list if they can suggest something.

I added;

Bharat> This takes care of only one part. In this section, we describe when to add the membership state, so we should also describe when to remove this state. For example: when a leave is received from a requestor, this membership state for this requestor will be removed. Similarly, if the group/source timer fires for a given group, all the membership state will also be removed.

It is readable?

Bharat> Yes, it seems ok.

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***