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-mai</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</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 </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) </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 ______________________________________________</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 consum</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) ----------------------------</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 addresse</pre> Bharat Joshi 2010-07-19T05:09:50 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.magma