Subject: [MBONED] Some questions and suggestions on Lightweight IGMPv3 and MLDv2 Protocols

From: Bharat Joshi <[email-masked]>
Date: Thu, 26 Jul 2007 19:43:09 +0530

Hi Hitoshi and all,

      I have some questions and suggestions on this draft. Some of them are for the text of the draft. I also feel that when a shorter version of protocol is defined in a new document, its always difficult to restrict yourself on what all details must be referenced and what details should be mentioned in the draft.

* I would suggest to reword the following sentence in Introduction:

"IGMPv3 and MLDv2 add the capability for a multicast router to also learn which sources are of interest to neighboring systems, for packets sent to any particular multicast address."

to

"IGMPv3 and MLDv2 add the capability to learn the sources which are of interest or which are of not interest for a particular multicast address. This information is used during forwarding of multicast data packets.

* I would suggest to reword the following sentence in Introduction:

"When a multicast router receives the report messages from its downstream hosts, it forwards the corresponding multicast traffic by managing requested group and source addresses."

to

"When a multicast router receives the report messages from its downstream hosts, it creates required state. This state is used to forwards the corresponding multicast traffic to the hosts.

* In the following statement:

"Group timers and source timers are used to maintain the forwarding state of desired groups and sources under certain filter modes."

I would suggest to replace "sources under certain filter modes" with "sources under filter modes defined in IGMPv3 and MLDv2".

* In following sentence:

"With all of the above factors correlating with each other, the determination rules become relatively complex, as the interface states could be frequently changed."

What are the determination rules here? I think its the forwarding state for each group per interface.

* In following sentence under 5th paragraph of Introduction:

"the protocol operations made by data receiver hosts and routers or"

I think 'end hosts' would be better than 'data receiver hosts'.

* Under section 2.1, typo in "(as known as (*,G) join )" , two 'as'

* Under section 2.2, in following sentence:

"The elimination of the filter-mode will greatly simplify the router"

I think 'exclude' is missing between 'the' and 'filter-mode'.

* In section 3.1, if the final source list is empty, an LW-xxx hosts must not send a State-Change Record except for TO_EX(). Right?

* In last section of 3.2, its mentioned that we can augment the source list if we receive a group-source specific query when a previous response with a non-empty source list exist. But should not we take a union of the list of sources here?
* I have an opinion to keep IS_EX and IS_IN instead of replacing them with TO_EX and ALLOW. I understand that operation on receipt of both types are same but this makes the protocol simple and easy to understand. IMHO, there is no difference in implementation.

* Last paragraph of section 3.3, typo in following sentence:

"used the following situation: the host first launches an application

I think a 'in' is missing between 'used' and 'the'.

* In section 4.1, source timer is always updated as and when a (S,G) join is received. Can we make this explicit?

* In section 4.2, I suggest to add following entries in the table:

While making forwarding decision, if data packet is coming from source 'S'.

 G_Timer == 0    Source 'S' does not          Do not forward traffic.
                 exist in the list

 G_Timer > 0     Source 'S' does not          Do not forward traffic.
                 exist in the list

* Under section 5.5.1, I would suggest reword the following sentence:

"The Host Compatibility Mode of an interface is set to IGMPv2 and IGMPv2 Querier Present is set to Older Version Querier Present Timeout second (defined in [2]) whenever an IGMPv2 General Query is received on that interface."

I did not understand "Older Version Querier Present Timeout second".

Thanks,
Bharat

**************** 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***

_______________________________________________
MBONED mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 27 Jul 2007 00:01:19 +0900 (JST)

Hi Bharat,

Thanks foy your detailed comments.
We'll carefully review all your points and reflect them if
appropriate.

Thanks,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 27 Jul 2007 00:01:19 +0900 (JST)

Hi Bharat,

Thanks,
--
Hitoshi Asaeda

---

From: Liu Hui <[email-masked]>
Date: Sat, 28 Jul 2007 10:21:29 +0800

Hi Bharat,

Thank  you very much for the detailed comments and suggestions.  Please see
our replies in line. 

Bharat Joshi wrote:
> 
> 
> Hi Hitoshi and all,
> 
>       I have some questions and suggestions on this draft. 
> Some of them are for the text of the draft. I also feel that 
> when a shorter version of protocol is defined in a new 
> document, its always difficult to restrict yourself on what 
> all details must be referenced and what details should be 
> mentioned in the draft.

Yes. This is also our original thinking when we compiled this draft. But
sometimes it is really difficult to have the choice when involving technical
details.

> "IGMPv3 and MLDv2 add the capability for a multicast router 
> to also learn which sources are of interest to neighboring 
> systems, for packets sent to any particular multicast address."
> 
> to
> 
> "IGMPv3 and MLDv2 add the capability to learn the sources 
> which are of interest or which are of not interest for a 
> particular multicast address. This information is used during 
> forwarding of multicast data packets.

Yes, the latter one is more complete in meaning 

> "When a multicast router receives the report messages from 
> its downstream hosts, it forwards the corresponding multicast 
> traffic by managing requested group and source addresses."
> 
> to
> 
> "When a multicast router receives the report messages from 
> its downstream hosts, it creates required state. This state 
> is used to forwards the corresponding multicast traffic to the hosts.

The latter one is more logical. But one thing to be mentioned is that some
report messages create states, while others  update or delete the created
states . We'll think it over to express it in a better way.

> "Group timers and source timers are used to maintain the 
> forwarding state of desired groups and sources under certain 
> filter modes."
> 
> I would suggest to replace "sources under certain filter 
> modes" with "sources under filter modes defined in IGMPv3 and MLDv2".

The latter one is more clear. 
 
> 
> * In following sentence:
> 
> "With all of the above factors correlating with each other, 
> the determination rules become relatively complex, as the 
> interface states could be frequently changed."
> 
> What are the determination rules here? I think its the 
> forwarding state for each group per interface.

The determination rule is used to decide how to make state updation when new
report arrives. E.g. When a multicast router receive a record , it will
check the type of the record and  its current state for this group in this
interface, decide the new interface group state, and take some actions as
required, such as adding or deleting sources, setting source timer or group
timer, or triggering queries.

> I think 'end hosts' would be better than 'data receiver hosts'.

End host is more concise, or just "host" is OK

> * Under section 2.1, typo in "(as known as (*,G) join )" , two 'as'

Yes, we'll correct it

> I think 'exclude' is missing between 'the' and 'filter-mode'.
Here elimination of the filter-mode means the filter-mode is not used in the
interface state equation. And filter-mode is also not used in the router
side state updation and in the forwarding decisions, as shown in the table
of section 4.2, 4.3, 4.4. While in full version of IGMPv3, filter-mode is
used in the corresponding equation and tables.

> * In section 3.1, if the final source list is empty, an 
> LW-xxx hosts must not send a State-Change Record except for 
> TO_EX(). Right?

The table in section 3.1 shows how the State-Change Record is sent when the
interface state for a host changes. In LW-IGMPv3, because excluding source
lists is not used, EXCLUDE(A) is not a valid state, with one exception for
EXCLUDE(NULL), which is used to represent (*,G)join. So the entries in the
table have the meaning that when the interface's final state changes to
EXCLUDE(NULL), LW-IGMPv3 host will send a TO_EX(NULL) record.

> 
> * In last section of 3.2, its mentioned that we can augment 
> the source list if we receive a group-source specific query 
> when a previous response with a non-empty source list exist. 
> But should not we take a union of the list of sources here?

The description in LW protocol here inherites that of the full igmpv3 (see
section 5.3 of RFC3376). Does union mean further merging of the sources in
the list? If does, this option should be evaluated carefully whether it has
any side effects on the protocol behavior

> * I have an opinion to keep IS_EX and IS_IN instead of 
> replacing them with TO_EX and ALLOW. I understand that 
> operation on receipt of both types are same but this makes 
> the protocol simple and easy to understand. IMHO, there is no 
> difference in implementation.

Yes, you are right. Our first version of individual draft defined the
messages with the TO_EX() discarded, the IS_EX() kept with only empty source
list,  and other message types reserved, just as you suggested. Now the
simplest form is adopted as the compromise of the mailing list and ideas of
the authors. Mo matter what kind of message set adopted, the processing of
LW-router are the same. 

> I think a 'in' is missing between 'used' and 'the'.

Yes, we'll correct it

> 
> * In section 4.1, source timer is always updated as and when 
> a (S,G) join is received. Can we make this explicit?

 (S,G) join is not used here because this denotion is not defined and used
through this document.

>  G_Timer > 0     Source 'S' does not          Do not forward traffic.

There are already two entries in the mentioned table  which I think have the
same meaning  with the above ones:

 G_Timer == 0   No Source Elements    Suggest not to forward
                                                                    traffic
from the source

 G_Timer > 0    No Source Elements    Suggest forwarding
                                                                   traffic
from source

And the second entry ( G_Timer > 0 ) identifies the state afer receiving the
(*,G) group join and the traffic are suggested to be forwarded for this
group.

> "The Host Compatibility Mode of an interface is set to IGMPv2 
> and IGMPv2 Querier Present is set to Older Version Querier 
> Present Timeout second (defined in [2]) whenever an IGMPv2 
> General Query is received on that interface."
> 
 
This expression is inherited from RFC 3376, please refer to section 7.2.1.
May "value" instead of "second" is easier to be understood . 

Best Regards,

Liu Hui

---

From: Liu Hui <[email-masked]>
Date: Sat, 28 Jul 2007 10:21:29 +0800

Hi Bharat,

 

Yes, we'll correct it

Yes, we'll correct it

 

Best Regards,

Liu Hui

---

From: Bharat Joshi <[email-masked]>
Date: Sat, 28 Jul 2007 15:31:12 +0530

Hi Liu,

     Please see my response in line. I have removed those comments and suggestion where we both are in sync.

Thanks,
Bharat

> states . We'll think it over to express it in a better way.

Yeah! What you mentioned is correct.

> timer, or triggering queries.

Ok. I misunderstood it. I thought it is referring to the forwarding state of the group. Can you please use the above mentioned text instead of using determination rules there? I think this is exactly why this new draft has been created and so more it is clear, better for the draft.

> End host is more concise, or just "host" is OK

At one or two places, you have used the term 'end hosts' in the text so I would suggest to use 'end host'.

> used in the corresponding equation and tables.

Ok. This is clear now.

> EXCLUDE(NULL), LW-IGMPv3 host will send a TO_EX(NULL) record.

This is fine. What I am pointing out is that if after calculating a interface state, source list for one of the report is NULL, that report is not sent by the host. Consider the below case:

INCLUDE (A)      INCLUDE (B)      ALLOW(B-A), BLOCK(A-B)

If (A-B) is a NULL source list, hosts do not generate a BLOCK report. I think we should mention this explicitly.

> any side effects on the protocol behavior

I checked section 5.3 of RFC 3376. It says exactly the same thing mentioned in your draft also. But my question still remains. When a response is pending with source 'A' and another query comes which is for 'B' so logically speaking we should take a union of 'A' and 'B' to generate the response.

I would suggest getting some expert's comments on this.

> the authors. Mo matter what kind of message set adopted, the processing of

Ok. So does that mean you are planning to keep IS_EX and IS_IN as it is?

> (*,G) group join and the traffic are suggested to be forwarded for this

Though the action taken in this case is same but 'No Source Elements' and a 'source' does not exist in the source list is too different points. That's why I suggested that we should have these two entries to make this explicit.

> May "value" instead of "second" is easier to be understood .

Yes. This is a timeout value.

---

From: Bharat Joshi <[email-masked]>
Date: Sat, 28 Jul 2007 15:31:12 +0530

Hi Liu,

Thanks,
Bharat

Ok. This is clear now.

---

From: Liu Hui <[email-masked]>
Date: Tue, 31 Jul 2007 17:31:48 +0800

Hi, Bharat

Sorry for the delay. Please see our comments inline

Bharat Joshi wrote:

> Ok. I misunderstood it. I thought it is referring to the 
> forwarding state of the group. Can you please use the above 
> mentioned text instead of using determination rules there? I 
> think this is exactly why this new draft has been created and 
> so more it is clear, better for the draft.

About this one and other editoral improvements, we'll take them into account
when making updation of the new version 

> I checked section 5.3 of RFC 3376. It says exactly the same 
> thing mentioned in your draft also. But my question still 
> remains. When a response is pending with source 'A' and 
> another query comes which is for 'B' so logically speaking we 
> should take a union of 'A' and 'B' to generate the response.
> 

OK. But maybe this is more appropriate for the improvement to the full
IGMPv3 rather than to the lightweight protocol

> 
> > > * I have an opinion to keep IS_EX and IS_IN instead of replacing 
> > > them with TO_EX and ALLOW. I understand that operation on 
> receipt of 
> > > both types are same but this makes the protocol simple 
> and easy to 
> > > understand. IMHO, there is no difference in implementation.
> >
> > messages with the TO_EX() discarded, the IS_EX() kept with 
> only empty 
> > source list,  and other message types reserved, just as you 
> suggested. 
> > Now the simplest form is adopted as the compromise of the 
> mailing list 
> > and ideas of the authors. Mo matter what kind of message 
> set adopted, 
> > the processing of LW-router are the same.
> 

The first choice with IS_IN and IS_EX preserved has the advantage of good
understandability and compatibility . But the latter one adopts the least
number of packet types and exihibits better the "simplified"
characteristics. As mentioned earlier, which set is used does not influence
the lightweight router's behaviour.  

Even though at present we do not have the plan to keep IS_EX() and IS_IN(),
but if it is being thought by many of us as a better choice,  it is possible
that they are kept in the lightweight protocol. If necessary, we can make a
vote on the mailing list or have a discuss about it to make an agreement on
that. Or there is another possibility that the lightweight protocol
provides two alternatives, it is up to the implementor to make his choice on
his own favor.

> 
> Though the action taken in this case is same but 'No Source 
> Elements' and a 'source' does not exist in the source list is 
> too different points. That's why I suggested that we should 
> have these two entries to make this explicit.

Even though  there is difference between the two expressions,  the
difference is too tiny to be noted. The reason for this is that the source
list are composed of source elements. So IMHO "no source elements"  "source
does not exist in the source list" and "the source list is empty" all have
the same meaning. And this table is also derived from  RFC3376 (please refer
to section 6.3).

Thanks, 

Liu Hui

---

From: Liu Hui <[email-masked]>
Date: Tue, 31 Jul 2007 17:31:48 +0800

Hi, Bharat

Thanks, 

Liu Hui