http://blog.gmane.org/gmane.ietf.magma hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.magma/1397 <pre>All, The IESG has recently re-chartered the PIM working group. In doing so, they have added responsibility for handling work related to IGMP and MLD. To avoid any confusion, I have suggested that the magma mailing list be closed and all discussion of IGMP/MLD issues carried out on the PIM mailing list. My plan is to close this mailing list in the next week or so. Information on subscribing to the PIM mailing list is available at https://www.ietf.org/mailman/listinfo/pim. Regards, Brian </pre> Brian Haberman 2012-03-29T12:53:51 http://comments.gmane.org/gmane.ietf.magma/1396 <pre>Regarding IGMPProxy :--- Upstream Downstream H1 ------------------------------------- eth0 IGMPProxy eth2 -------------------------------------- H2 multicastsend multicastrecv UDP --&gt; &lt;---- JOIN With the above setup. Started pumping UDP stream from H1 to group 239.0.0.0/5000. After sending the IGMP JOIN on H2 side (to Grp 239.0.0.0), UDP stream started receiving properly to the port 5000. But it is observed that, udp stream is not recieved immediately to H2, it is taking 2 to 3 seconds some times, it is taking 4 to 6 seconds also. I hope that IGMPProxy implementation will add the Route in MFC, whenver it receives CACHE_MISS event and matches the JOIN database. In IGMP General queries sent, "Max Response Time" field is set to 1 second. Any better approach to avoid delayed stream Thanks in advance Ganesh </pre> Ganesh Reddy K 2012-03-14T07:12:54 http://comments.gmane.org/gmane.ietf.magma/1394 <pre>Hello folks, Multimob WG started WGLC for the following draft discussing IGMP/MLD timer or value tuning for wireless network or mobile communication. We'd appreciate hearing your comments on "multimob ML", not magma ML. (Just teling "support" on multimob ML is also fine. :) Regards, -- Hitoshi Asaeda _______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> Hitoshi Asaeda 2012-02-16T11:34:33 http://comments.gmane.org/gmane.ietf.magma/1392 <pre>Hi, If we have enabled both IGMP and IGMP snooping, and we receive query from a neighbor, should we always create the dynamic mrouter(since snooping is enabled). Thanks, Sudhanshu _______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> sudhanshu kumar 2012-02-10T04:43:41 http://comments.gmane.org/gmane.ietf.magma/1386 <pre>Hi, If we have IGMP enabled on VE(virtual ethernet) with some member ports and a new member port joins the VE, is it necessary to send query on that port immediately, or we can send query on expiry of query interval timer. What are the consequences of delaying the "send query message" on the newly joining port. Thanks, Sudhanshu _______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> sudhanshu kumar 2012-02-01T12:09:13 http://comments.gmane.org/gmane.ietf.magma/1385 <pre>Hi, I have one question regarding IGMP Snooping. Usually we forward query to mrouter ports of the receiving vlan. Can there be a scenario where I need to forward the query to mrouter ports of other vlans? If yes then what is the case? Thanks, Indranil _______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> Indranil Bhattacharya 2012-02-01T11:16:39 http://comments.gmane.org/gmane.ietf.magma/1377 <pre>_______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> Indranil Bhattacharya 2012-01-31T03:26:50 http://comments.gmane.org/gmane.ietf.magma/1360 <pre>Hi, Can anyone please tell me the disadvantage of using queriers address as destination address in v2 leave message? Is there any advantage of sending it to 224.0.0.2? Non-querier never processes leave message anyway. Thanks, Indranil _______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> Indranil Bhattacharya 2011-10-13T17:30:27 http://comments.gmane.org/gmane.ietf.magma/1348 <pre>Hi all, Can an IGMPv2 host respond to a general query originated from a subnet other then its own?? RFC 2236 states: ""query received" occurs when the host receives either a valid General Membership Query message, or a valid Group-Specific Membership Query message. To be valid, the Query message must be at least 8 octets long, and have a correct IGMP checksum. The group address in the IGMP header must either be zero (a General Query) or a valid multicast group address (a Group-Specific Query)" There is no requirement for the source address to be on the same subnet as the host. Thanks, Kunal _______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> Kunal Shah 2011-10-12T00:38:31 http://comments.gmane.org/gmane.ietf.magma/1346 <pre>Hi All, I am not sure if people are aware of this. The new charter of PIM working-group now includes work on IGMP/MLD protocol as well. So if you are interested in these protocols, please subscribe to PIM working-group mailing list as well. Apologies if you are already on PIM working-group list or are aware of this. Regards, 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*** </pre> Bharat Joshi 2011-05-09T05:14:30 http://comments.gmane.org/gmane.ietf.magma/1344 <pre>Hi All, Had a question regarding the MLD router behavior when MLD is enabled on an interface with reference to Neighbor Discovery RFC 4861 attached below for reference: ******* RFC 4861 ************ 7.2.1. Interface Initialization When a multicast-capable interface becomes enabled, the node MUST join the all-nodes multicast address on that interface, as well as the solicited-node multicast address corresponding to each of the IP addresses assigned to the interface. The set of addresses assigned to an interface may change over time. New addresses might be added and old addresses might be removed [ADDRCONF]. In such cases the node MUST join and leave the solicited-node multicast address corresponding to the new and old addresses, respectively. Joining the solicited-node multicast address is done using a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols. Note that multiple unicast addresses may map into the same solicited-node multicast address; a node MUST NOT leave the solicited-node multicast group until all assigned addresses corresponding to that multicast address have been removed. *********** What are the MLD join packets that should be sent when the interface has version MLDv1 and when the version is MLDv2. Is there some IETF document that provides more details on this behavior. Have not found any clear description in RFCs 3810 or 2710. regards, -rekha _______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> Rekha Mundhra 2011-04-22T22:23:10 http://comments.gmane.org/gmane.ietf.magma/1334 <pre>Hi all, I have a question about IGMPv3 state machine. If a group is in EX(X,Y) and a TO_IN(A) is received, the new state according to the RFC is EX (X+A, Y-A). I think this mean remove all the elements of A from Y and add all elements of A to X. This also implies that sources not removed from Y will still end up being added to X. My question is why cant we add only those elemets of A to X which are removed from Y as opposed to adding all the elements of A to X ?? If only the elements that are removed from Y are added to X, the new state would look like EX (X+(Y*A), Y-A). Am I missing something here?? Kunal _______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> Kunal Shah 2011-02-14T19:58:55 http://comments.gmane.org/gmane.ietf.magma/1332 <pre>Hi All, If there are two IGMP routers on a LAN, one of them gets elected as querier and another as non-querier. The querier sends query and hosts on that LAN reply with the reports. Querier sees those report and create a database. Non-querier also sees those report and would create the same database. Question is whether Multicast routing protocol running on non-querier's upstream interface should use this database to join/leave the multicast group or not? IIRC, it is required because the DR for that LAN could be the non-querier router and if we do not join upstream, multicast data won't flow to this router. Is this a correct thinking? Regards, 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*** </pre> Bharat Joshi 2011-02-14T05:01:40 http://comments.gmane.org/gmane.ietf.magma/1331 <pre> Hello, I need a couple of clarifications in MldV2 Rfc 3810. 1) In section 7.4,1 "Reception of Current State Records", I see the following operation EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y, Y*A) (A-X-Y)=MALI Delete (X-A) Delete (Y-A) Filter Timer=MALI Whether the src timer (A-X-Y) should be set to Filter timer instead of MALI. Why we need to set the src Timer for these srcs to MALI ?. Setting it to MALI will take longer time for these srcs to get excluded. Note that TO_EXC report handling sets them to Filter timer instead of MALI. EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y) = Filter Timer Delete (X-A) Delete (Y-A) Send Q(MA,A-Y) Filter Timer=MALI 2) Regarding src deletion when there is a GSSQ retransmission scheduled for it: Lets take the following reports: Report A { M1, IS_IN (S1, S2) } Report B { M1, TO_EX (S1,S2) } Report C { M1, IS_EX ( S1,S3) } Step 1)* Send Report A * Router will have following information for Multicast address M1, State - Include src-include-list - S1, S2 Step 2) *Send Report B * After handling Report B, following will be the state information for M1 State - Exclude Src-Req-list : S1,S2 Src-Exc-List: Empty There will be a GSSQ packet send for S1 and S2 with Sbit Unset. There will be another GSSQ packet scheduled for these srcs (S1 and S2) later at LLQT interval. Step 3) *Send Report C* before the scheduled GSSQ for S1 and S2 is transmitted. According to the state table, Report C handling will delete the src S2 (Delete (X-A) ). EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y) = Filter Timer Delete (X-A) Delete (Y-A) Send Q(MA,A-Y) Filter Timer=MALI However there is an GSSQ pending for the src S2. So what we do now ? Delete the src S2 and cancel the retransmission ? Or delete the src but do not cancel the retransmission ?. If we are not canceling the retransmission, whether Sbit should be True for this query ?. I believe we should delete the src and this in turn should cancel the GSSQ retransmission for this src as well. Let me know if anybody has any thoughts on this. regards, Balaji _______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> Balaji Sankaran 2010-11-10T07:13:37 http://comments.gmane.org/gmane.ietf.magma/1321 <pre>Hi all, According to RFC 4605, a router creates a membership database after merging the subscriptions on individual interfaces. Lets say that 3 IGMPv3 capable interfaces are as follows: Interface 1 has host reporting Include S1 -&gt; I(S1) Interface 2 has host reporting Exclude S2 -&gt; E(0,S2) Interface 3 has host reporting Exclude nothing -&gt; E(0,0) For a device doing IGMPv3 proxy, the final membership record for group G is (G, EXCLUDE, NULL). Now lets say the host on interface 3 goes away, because of which the subscription on interface 3 would expire and there wont be any IGMPv3 state on interface 3. How would the new membership record for PROXY be calculated?? The RFC does not suggest any way to do this. Would IGMP process have to go through each interface again and then recompute the new membership record?? This would be very inefficient especially if there are multiple interfaces. Is there a better way to recompute the new membership record?? Thanks Kunal _______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> Kunal Shah 2010-10-30T00:46:35 http://comments.gmane.org/gmane.ietf.magma/1318 <pre>Hi all, Is there any reason to send out a query in fast-leave is enabled on the interface?? Enabling fast-leave allows deleting the cache immediately on receiving a leave. If the cache is deleted immediately, hosts on the interface will see traffic loss, which makes me think that fast-leave is enabled when the interface is gauranteed to receive a leave when the last host goes away or there is only one host on the interface. So does it make any sense in sending out a query on receiving a leave if fast-leave is enabled?? Thanks Kunal _______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> Kunal Shah 2010-10-28T22:46:50 http://comments.gmane.org/gmane.ietf.magma/1314 <pre>Hi all, I have another question. About a size limit of a Multicast Address Specific Query in MLDv2. How is a query transmitted when the number of multicast source addresses of a query message is limited by the MTU? Is a Query split like a Report type IS_IN? (It isn't a Query like Report type IS_EX, is it?) RFC3810 ------------------------------------------------------------------------ 5. Message Formats 5.1. Multicast Listener Query Message 5.1.10. Number of Sources (N) The Number of Sources (N) field specifies how many source addresses are present in the Query. This number is zero in a General Query or a Multicast Address Specific Query, and non-zero in a Multicast Address and Source Specific Query. This number is limited by the MTU of the link over which the Query is transmitted. For example, on an Ethernet link with an MTU of 1500 octets, the IPv6 header (40 octets) together with the Hop-By-Hop Extension Header (8 octets) that includes the Router Alert option consume 48 octets; the MLD fields up to the Number of Sources (N) field consume 28 octets; thus, there are 1424 octets left for source addresses, which limits the number of source addresses to 89 (1424/16). 5.2. Version 2 Multicast Listener Report Message 5.2.15. Multicast Listener Report Size If the set of Multicast Address Records required in a Report does not fit within the size limit of a single Report message (as determined by the MTU of the link on which it will be sent), the Multicast Address Records are sent in as many Report messages as needed to report the entire set. If a single Multicast Address Record contains so many source addresses that it does not fit within the size limit of a single Report message, then: o if its Type is not IS_EX or TO_EX, it is split into multiple Multicast Address Records; each such record contains a different subset of the source addresses, and is sent in a separate Report. o if its Type is IS_EX or TO_EX, a single Multicast Address Record is sent, with as many source addresses as can fit; the remaining source addresses are not reported. Although the choice of which sources to report is arbitrary, it is preferable to report the same set of sources in each subsequent report, rather than reporting different sources each time. Best Regards -- Kiyoaki Kawaguchi </pre> K.Kawaguchi 2010-09-28T07:28:37 http://comments.gmane.org/gmane.ietf.magma/1310 <pre>Hi all, I have a simple question for MLDv2 interoperation with MLDv1. RFC3810 --- 8.3. Multicast Router Behavior 8.3.2. In the Presence of MLDv1 Multicast Address Listeners MLDv2 BLOCK messages are ignored, as are source-lists in TO_EX() messages (i.e., any TO_EX() message is treated as TO_EX( {} )). On the other hand, the Querier continues to send MLDv2 queries, regardless of its Multicast Address Compatibility Mode. --- Is the follwing a correct right too? "Any IS_EX() message is treated as IS_EX( {} )." Best Regards -- Kiyoaki Kawaguchi </pre> K.Kawaguchi 2010-09-27T03:16:21 http://comments.gmane.org/gmane.ietf.magma/1306 <pre>_______________________________________________ magma mailing list magma&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/magma </pre> Kunal Shah 2010-09-17T21:14:13 http://comments.gmane.org/gmane.ietf.magma/1305 <pre> The following errata report has been submitted for RFC3678, "Socket Interface Extensions for Multicast Source Filters". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3678&amp;eid=2524 -------------------------------------- Type: Technical Reported by: YOSHIFUJI Hideaki &lt;yoshfuji&lt; at &gt;linux-ipv6.org&gt; Section: 5.2.2 Original Text ------------- The interface argument holds the local IP address of the interface. Corrected Text -------------- The interface argument holds the interface index of the interface. Notes ----- See Section 5.2.1. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3678 (draft-ietf-magma-msf-api-05) -------------------------------------- Title : Socket Interface Extensions for Multicast Source Filters Publication Date : January 2004 Author(s) : D. Thaler, B. Fenner, B. Quinn Category : INFORMATIONAL Source : Multicast &amp; Anycast Group Membership Area : Internet Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2010-09-16T08:08:07 http://comments.gmane.org/gmane.ietf.magma/1296 <pre>Hi All, I was re-reading RFC 3376 for handling compatibility for lower version of querier. In section 7.3.1, it is mentioned that a querier configured to run in V3 mode should lower its version when it sees a lower version query on the same network. From that time onwards, a router should send the lower version queries. Now the question is, when this router should revert back to its configured higher version? The text in section 7.3.1 or elsewhere does not talk about this. Should a timer 'lower_version_querier' be started and updated as and when lower version queries are removed? Please note this is not same as other-querier-present timer. Can someone, who has implemented IGMPv3, let me know how this particular case has been handled in their implementation? Regards, 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*** </pre> Bharat Joshi 2010-07-19T05:09:50 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.magma