From owner-idmr@cs.ucl.ac.uk Fri Dec 1 17:27:32 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09893 for ; Fri, 1 Dec 2000 17:27:31 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 1 Dec 2000 20:24:46 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 1 Dec 2000 20:24:40 +0000 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 1 Dec 2000 20:24:45 +0000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 0DF6F4CE46 for ; Fri, 1 Dec 2000 15:24:40 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA07713 for ; Fri, 1 Dec 2000 15:24:38 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA02248; Fri, 1 Dec 2000 12:24:38 -0800 (PST) Message-Id: <200012012024.MAA02248@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idmr@cs.ucl.ac.uk Subject: IDMR Agenda Date: Fri, 1 Dec 2000 12:24:38 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Agenda Bashing 5 Minutes Document Status 15 Minutes MIBS Source Filtering API IGMPv3 Router Behavior Last Call Summaries 10 Minutes DVMRP spec, AS, MIB IGMPv3 Multicast Router Discovery New work items? 5 Minutes Using MBGP to distribute multicast topology (similar to RFC2545) ? WG future 5 Minutes From owner-idmr@cs.ucl.ac.uk Wed Dec 6 10:37:49 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01261 for ; Wed, 6 Dec 2000 10:37:48 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 6 Dec 2000 13:21:37 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Dec 2000 13:21:30 +0000 Received: from smtp4.cluster.oleane.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 6 Dec 2000 13:21:35 +0000 Received: from oleane (dyn-1-1-091.Vin.dialup.oleane.fr [195.25.4.91]) by smtp4.cluster.oleane.net with SMTP id eB6DLYi97537 for ; Wed, 6 Dec 2000 14:21:34 +0100 (CET) Message-ID: <00bd01c05f87$c65ed020$8001a8c0@oleane.com> From: Peter Lewis To: idmr Subject: IP.Net call for papers Date: Wed, 6 Dec 2000 14:23:51 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01C05F90.27D87380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00BA_01C05F90.27D87380 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The dead line for the IP.Net call for papers has been postponed to = December 22nd. Get more details at: http://www.upperside.fr/baipnet.htm Due to the success of the exhibition part, the event will take place = from 19 to 22 June at the Sofitel Hotel in Paris. ------=_NextPart_000_00BA_01C05F90.27D87380 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The dead line for the IP.Net call = for papers has=20 been postponed to December 22nd.
Get more details at:
http://www.upperside.fr/baip= net.htm
Due to the success of the exhibition = part, the=20 event will take place from 19 to 22 June at the Sofitel Hotel in=20 Paris.
 
------=_NextPart_000_00BA_01C05F90.27D87380-- From owner-idmr@cs.ucl.ac.uk Mon Dec 11 06:04:05 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19910 for ; Mon, 11 Dec 2000 06:04:04 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 11 Dec 2000 08:28:27 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 11 Dec 2000 08:28:20 +0000 Received: from smtp2.cluster.oleane.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 11 Dec 2000 08:28:26 +0000 Received: from oleane (dyn-1-1-004.Vin.dialup.oleane.fr [195.25.4.4]) by smtp2.cluster.oleane.net with SMTP id eBB8SLc99202 for ; Mon, 11 Dec 2000 09:28:21 +0100 (CET) Message-ID: <017201c0634c$9f56bce0$8001a8c0@oleane.com> From: Peter Lewis To: idmr Subject: "Betond Sonet/SDH" Call for paper Date: Mon, 11 Dec 2000 09:30:28 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016F_01C06354.FFED0520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_016F_01C06354.FFED0520 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Gigabit Ethernet Digital Wrapper Issues Implementation of newly defined functionalities: STM-64, STM-256 = (positioning beside N x 2.5 G or P x 10 G)=20 Tandem connection monitoring FEC WDM DWDM issues:=20 - Transitional step between SDH and OTN=20 - Terabit networks - WDM for metro networks=20 The call for paper for the "Betond Sonet/SDH" conference has been = extended to January 20. Please take a look on: http://www.upperside.fr/babeyondsdh.htm ------=_NextPart_000_016F_01C06354.FFED0520 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Gigabit Ethernet
Digital Wrapper Issues
Implementation of newly defined functionalities: STM-64, STM-256=20 (positioning beside N x 2.5 G or P x 10 G)
Tandem connection = monitoring FEC=20 WDM DWDM issues:
- Transitional step between SDH and OTN
- = Terabit=20 networks
- WDM for metro networks
 
The call for paper for the "Betond Sonet/SDH" conference has been = extended=20 to January 20.
 
Please take a look on:
http://www.upperside.fr/= babeyondsdh.htm
------=_NextPart_000_016F_01C06354.FFED0520-- From owner-idmr@cs.ucl.ac.uk Tue Dec 12 06:24:30 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09710 for ; Tue, 12 Dec 2000 06:24:25 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 12 Dec 2000 08:37:08 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Dec 2000 08:37:01 +0000 Received: from suraksha.wipsys.soft.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 12 Dec 2000 08:37:01 +0000 Received: by suraksha.wipro.com (8.8.8+Sun/SMI-SVR4) id OAA07801; Tue, 12 Dec 2000 14:02:33 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma007790; Tue, 12 Dec 00 14:02:22 +0530 Received: from krishnansub ([192.168.162.181]) by bhairavi.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA54CF for ; Tue, 12 Dec 2000 13:58:26 +0530 Message-ID: <007101c06416$6bac83a0$b5a2a8c0@wipsys.soft.net> From: Krishnan Subramaniam To: idmr Subject: clarification on NAT Date: Tue, 12 Dec 2000 14:05:01 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed ; boundary="----=_NextPart_000_006E_01C06444.84EF4180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_006E_01C06444.84EF4180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello, i have the following clarifications regarding NAT. 1-)how are the routing lookup done in a NAT router ? a) whether the routing entries are based on virtual (translated)address (or) , b) or whether the entries are based on private or=20 inner network address ; in case of (a) while converting the destination address from outer to inner the lookup has to be done first before the conversion , while in case (b) it has to be the reverse while CISCO has suggested (b) intel has suggested (a); Intel's case is applicable when both sides of the NAT router has private address (e.g. 10.1.0.0) they have to be translated as (10.2.0.0) from interface-A to interface-B and as (10.3.0.0)=20 from interface-B to interface-A. In this case the routing table has to have the entries for 10.2.0.0 and 10.3.0.0 and not 10.1.0.0=20 what is the correct way , or what is the way out for handling both case (a) and (b) ; 2-)regarding PAT , how is the destination address translation=20 taken care off when there is IP-fragmentation ;=20 Generally we hash (src addr, src port ) to (assigned addr , assig- ned port) when we do the translation from inner to outer ; While there is no problem in hash lookup from inside to outside translation the hash look up is not possible for outside to inside translation except for the first fragment - the other fragments do not have UDP or TCP header for which we still have to translate the destination=20 ip-address ; In this case do we have to create a entry for the translation when we see the frist fragment with the ip-identifier (with offset =3D zero) and then for subsequent fragments with the same=20 Id do a hash lookup with the Identifier field ; this appears to be=20 the solution ; is there a alternate way ? thanking you before hand for your suggestions krishnan =20 ------=_NextPart_000_006E_01C06444.84EF4180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello,
 
i have the following clarifications regarding = NAT.
 
1-)how are the routing lookup done = in a NAT=20 router ?
    a) whether = the routing entries are based on virtual
       =20 (translated)address (or) ,
    b) or=20 whether the entries are based on private or
    inner network address ;
 
in case of (a) while converting the = destination=20 address
from outer to inner the lookup has to be done = first=20 before
the conversion , while in case (b) = it has to be=20 the reverse
 
while CISCO has suggested (b) intel has = suggested=20 (a);
 
Intel's case is applicable = when both sides=20 of the NAT router
has private address (e.g. = 10.1.0.0) they=20 have to be translated
as (10.2.0.0) from interface-A to interface-B = and as=20 (10.3.0.0)
from interface-B = to=20 interface-A. In this case the routing
table has to have the entries for 10.2.0.0 = and 10.3.0.0=20 and not
10.1.0.0
 
what is the correct way , or what is = the way out=20 for handling
both case (a) and (b) ;
 
 
2-)regarding PAT , how is the destination = address=20 translation
taken care off when there is IP-fragmentation = ;=20
 
Generally we hash (src addr, src port ) to = (assigned=20 addr , assig-
ned port) when we do the translation from = inner to=20 outer ; While
there is no problem in hash lookup from = inside to=20 outside translation
the hash look up is not possible for outside = to inside=20 translation
except for the first fragment - the other = fragments do=20 not have UDP
or TCP header for which we still have to = translate the=20 destination
ip-address ; In this case do we have to = create a entry=20 for the
translation when we see the frist fragment = with the=20 ip-identifier
(with offset =3D zero) and=20 then for subsequent fragments with the same
Id do a hash lookup with the Identifier field = ; this=20 appears to be 
the solution ;
 
is there a alternate way = ?
 
thanking you before hand for your=20 suggestions
 
krishnan
 
 
 
 
 
 
 
 
 
------=_NextPart_000_006E_01C06444.84EF4180-- From owner-idmr@cs.ucl.ac.uk Wed Dec 13 14:53:10 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10815 for ; Wed, 13 Dec 2000 14:53:09 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 13 Dec 2000 17:14:07 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 13 Dec 2000 17:13:59 +0000 Received: from isis.lip6.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 13 Dec 2000 17:14:06 +0000 Received: from rp.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.9.3/jtpda-5.3.2) with ESMTP id SAA08370 ; Wed, 13 Dec 2000 18:14:04 +0100 Received: from lip6.fr (otos.lip6.fr [132.227.61.47]) by rp.lip6.fr (8.8.8/jtpda-5.2) with ESMTP id SAA10747 ; Wed, 13 Dec 2000 18:14:03 +0100 (MET) Message-ID: <3A37AE5A.413ADF83@lip6.fr> Date: Wed, 13 Dec 2000 18:14:02 +0100 From: Rolland Vida Organization: Laboratoire Lip6 X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: fenner@research.att.com, deering@cisco.com, kouvelas@cisco.com, idmr@cs.ucl.ac.uk, Serge Fdida , Luis Costa Subject: RE: WG Last Call: IGMP Version 3 to Proposed Standard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Following are our main comments on the IGMPv3 (draft-05) document: In section 6.2.1 of the draft it is written: "Conceptually, when a group record is received, the router filter-mode for that group is updated to represent the most number of sources desired with the least amount of state." This sentence is not very clear, as the filter mode should be updated to permit the reception of ALL the requested sources, and not "the most number of sources". The present phrasing could be (wrongly) taken in a sense that we might ignore sources in order not to increase state. What do you think instead about the following text: "the router filter-mode for that group is updated to cover all the requested sources using the least amount of state. "? ------------------------------------------------------------------------------- In section 6.2.3 it is written: " If a source record has a running timer with a router filter-mode for the group of EXCLUDE, it means that a "conflict" has occurred with respect to desired reception state of that source (i.e. at least one system desires the source and another one doesn't)." This is not always true, as sources could be desired by all the hosts and still be in the source list of a router in Exclude mode, with a running timer. Let's take an example. Suppose that Host1 sends a report IS_EX(S1) for a group G. It means that it asks for reception of all sources for G, but source S1. The router state after reception will be Exclude((), (S1)). If Host2 sends now a report IS_IN(S2) for the same group G, the router state will be modified, according to the draft, to Exclude ((S2),(S1)). Source S2 will be included in the source list of the router, and its timer will be initialised to GMI. However, source S2 is not a "conflicting" source, as both hosts desire it. We propose thus the following text: "If a source record has a running timer with a router filter-mode for the group of EXCLUDE, it means that at least one system desires the source, it should thus be forwarded by a router on the network. . However, if that system, or any other system, does not confirm its desire in receiving that source before its timer expires, it's forwarding will be stopped". ---------------------------------------------------------------------------- In section 6.3, in the table that describes the forwarding suggestions made by IGMP, it is written: INCLUDE TIMER == 0 Suggest to stop forwarding traffic from source and remove source record Shouldn't we eliminate the whole group record, once all the source records are deleted? In section 6.2.2, it is explicitely specified in the table that we should delete the group record if the filter is Exclude, and the group timer and all the source timers have expired. Shouldn't we do the same explicit deletion when the filter is in Include? We could for example rephrase the line as follows: INCLUDE TIMER ==0 Suggest to stop forwarding traffic from source and remove source record. If there are no more source records for the group, delete group record. ----------------------------------------------------------------------------------- Starting with section 6.4, the draft uses the expression "Exclude (X,Y)" to say that sources in the first set, X, have timers greater than zero and will be forwarded, while sources in the second set, Y, have timers equal to zero and all hosts agree on not to forward them. This may create a bit of confusion, as previously, in section 6.2.1, you stated: "When a router filter-mode for a group is EXCLUDE, the source record list contains two types of sources. The first type is the set of sources which hosts have requested to not be forwarded. The second set is the set which represents conflicts in the desired reception state; this set must be forwarded by some router on the network.". So the first set from section 6.2.1 is actually the second set in 6.4, and the second set in 6.2.1 is the first one in 6.4. To avoid confusion, maybe it would be good to swap the order of the sets in the phrase in section 6.2.1 ----------------------------------------------------------------------------------- In section 6.4.1, in the last line of the table, we have the following: Router State Report Rec'd New Router State ------------ ------------ ---------------- EXCLUDE (X,Y) IS_EX (A) EXCLUDE (X*A+(A-Y),Y*A) However, X*Y=() (obvious, because of the way we construct them) Therefore, if S in X*A then S in X, so S is not in Y But in the meantime, if S in X*A then S in A Conclusion: if S in X*A then S is in A-Y. So X*A is included in A-Y. We could thus simplify the new router state to Exclude (A-Y, Y*A) The same reasoning holds for the penultimate line of the table from section 6.4.2. ----------------------------------------------------------------------------------- In table in section 6.4.2, we have the following: Router State Report Rec'd New Router State Actions ------------ ------------ ---------------- ------- EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) Send Q(G,A-Y) However, if a host sends a BLOCK(A) report, it means that sources from A were forwarded until then, so they are not in Y. We could thus simplify the new router state to Exclude (X+A, Y). We need also a conforming action for the sending of the query. The same reasoning holds for the next line of the table. -------------------------------------------------------------------------- . In section 6.6.1., it is treated only the case of a query with the Suppress Router-Side Processing flag not set. Maybe you could add the following phrase at the end of the section, in order to make the text clearer: "When a router sends or receives a query with the Suppress Router-Side Processing flag set, it will not update its timers". From owner-idmr@cs.ucl.ac.uk Thu Dec 14 14:11:41 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19170 for ; Thu, 14 Dec 2000 14:11:40 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 14 Dec 2000 17:34:19 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Dec 2000 17:34:12 +0000 Received: from sj-msg-core-2.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 14 Dec 2000 17:34:17 +0000 Received: from irp-view6.cisco.com (irp-view6.cisco.com [171.69.25.17]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA20201; Thu, 14 Dec 2000 09:33:41 -0800 (PST) Received: from localhost (kouvelas@localhost) by irp-view6.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA05437; Thu, 14 Dec 2000 09:33:37 -0800 (PST) Message-Id: <200012141733.JAA05437@irp-view6.cisco.com> X-Authentication-Warning: irp-view6.cisco.com: kouvelas owned process doing -bs To: Rolland Vida cc: fenner@research.att.com, deering@cisco.com, kouvelas@cisco.com, idmr@cs.ucl.ac.uk, Serge Fdida , Luis Costa Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard In-reply-to: Your message of "Wed, 13 Dec 2000 18:14:02 +0100." <3A37AE5A.413ADF83@lip6.fr> Date: Thu, 14 Dec 2000 09:33:37 -0800 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Thanks we have used all your comments except one. See below. Rolland Vida writes: >Following are our main comments on the IGMPv3 (draft-05) document: > >In section 6.2.1 of the draft it is written: "Conceptually, when a group >record is received, the router filter-mode for that group is updated to >represent the most number of sources desired with the least amount of >state." > >This sentence is not very clear, as the filter mode should be updated to >permit the reception of ALL the requested sources, and not "the most >number of sources". The present phrasing could be (wrongly) taken in a >sense that we might ignore sources in order not to increase state. > >What do you think instead about the following text: "the router >filter-mode for that group is updated to cover all the requested sources >using the least amount of state. "? > >------------------------------------------------------------------------------ >- > >In section 6.2.3 it is written: " If a source record has a running timer >with a router filter-mode for the group of EXCLUDE, it means that a >"conflict" has occurred with respect to desired reception state of that >source (i.e. at least one system desires the source and another one >doesn't)." > >This is not always true, as sources could be desired by all the hosts >and still be in the source list of a router in Exclude mode, with a >running timer. Let's take an example. Suppose that Host1 sends a report >IS_EX(S1) for a group G. It means that it asks for reception of all >sources for G, but source S1. The router state after reception will be >Exclude((), (S1)). If Host2 sends now a report IS_IN(S2) for the same >group G, the router state will be modified, according to the draft, to >Exclude ((S2),(S1)). Source S2 will be included in the source list of >the router, and its timer will be initialised to GMI. However, source S2 >is not a "conflicting" source, as both hosts desire it. > >We propose thus the following text: "If a source record has a running >timer with a router filter-mode for the group of EXCLUDE, it means that >at least one system desires the source, it should thus be forwarded by a >router on the network. . However, if that system, or any other system, >does not confirm its desire in receiving that source before its timer >expires, it's forwarding will be stopped". > >---------------------------------------------------------------------------- > >In section 6.3, in the table that describes the forwarding suggestions >made by IGMP, it is written: > > INCLUDE TIMER == 0 Suggest to stop forwarding > traffic from source and remove > source record > >Shouldn't we eliminate the whole group record, once all the source >records are deleted? In section 6.2.2, it is explicitely specified in >the table that we should delete the group record if the filter is >Exclude, and the group timer and all the source timers have expired. >Shouldn't we do the same explicit deletion when the filter is in >Include? We could for example rephrase the line as follows: > >INCLUDE TIMER ==0 Suggest to stop forwarding > traffic from source and remove > source record. If there are no more > source records for the group, > delete group record. > >------------------------------------------------------------------------------ >----- > >Starting with section 6.4, the draft uses the expression "Exclude (X,Y)" >to say that sources in the first set, X, have timers greater than zero >and will be forwarded, while sources in the second set, Y, have timers >equal to zero and all hosts agree on not to forward them. This may >create a bit of confusion, as previously, in section 6.2.1, you stated: >"When a router filter-mode for a group is EXCLUDE, the source record >list contains two types of sources. The first type is the set of >sources which hosts have requested to not be forwarded. The second set >is the set which represents conflicts in the desired reception state; >this set must be forwarded by some router on the network.". > >So the first set from section 6.2.1 is actually the second set in 6.4, >and the second set in 6.2.1 is the first one in 6.4. To avoid confusion, >maybe it would be good to swap the order of the sets in the phrase in >section 6.2.1 > >------------------------------------------------------------------------------ >----- > >In section 6.4.1, in the last line of the table, we have the following: > > Router State Report Rec'd New Router State > ------------ ------------ ---------------- > > EXCLUDE (X,Y) IS_EX (A) EXCLUDE (X*A+(A-Y),Y*A) > >However, X*Y=() (obvious, because of the way we construct them) >Therefore, if S in X*A then S in X, so S is not in Y >But in the meantime, if S in X*A then S in A >Conclusion: if S in X*A then S is in A-Y. So X*A is included in A-Y. >We could thus simplify the new router state to Exclude (A-Y, Y*A) >The same reasoning holds for the penultimate line of the table from >section 6.4.2. > >------------------------------------------------------------------------------ >----- > >In table in section 6.4.2, we have the following: > Router State Report Rec'd New Router State Actions > ------------ ------------ ---------------- ------- > > EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) Send Q(G,A-Y) > >However, if a host sends a BLOCK(A) report, it means that sources from A >were forwarded until then, This is not necessarily true as there might have been an inconsistency between the host and the router (caused by more than robustness missed messages). thanks Bill & Isidor >so they are not in Y. We could thus simplify >the new router state to Exclude (X+A, Y). We need also a conforming >action for the sending of the query. The same reasoning holds for the >next line of the table. > >-------------------------------------------------------------------------- > >. >In section 6.6.1., it is treated only the case of a query with the >Suppress Router-Side Processing flag not set. Maybe you could add the >following phrase at the end of the section, in order to make the text >clearer: > >"When a router sends or receives a query with the Suppress Router-Side >Processing flag set, it will not update its timers". > > > > > > > > > From owner-idmr@cs.ucl.ac.uk Thu Dec 14 14:11:49 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19203 for ; Thu, 14 Dec 2000 14:11:48 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 14 Dec 2000 18:01:17 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Dec 2000 18:01:09 +0000 Received: from isis.lip6.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 14 Dec 2000 18:01:16 +0000 Received: from rp.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.9.3/jtpda-5.3.2) with ESMTP id TAA19583 ; Thu, 14 Dec 2000 19:01:15 +0100 Received: from lip6.fr (otos.lip6.fr [132.227.61.47]) by rp.lip6.fr (8.8.8/jtpda-5.2) with ESMTP id TAA10519 ; Thu, 14 Dec 2000 19:01:15 +0100 (MET) Message-ID: <3A390AEA.6B36AFD6@lip6.fr> Date: Thu, 14 Dec 2000 19:01:15 +0100 From: Rolland Vida Organization: Laboratoire Lip6 X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: Isidor Kouvelas CC: fenner@research.att.com, deering@cisco.com, idmr@cs.ucl.ac.uk, Serge Fdida , Luis Costa Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard References: <200012141733.JAA05437@irp-view6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit > >However, if a host sends a BLOCK(A) report, it means that sources from A > >were forwarded until then, > > This is not necessarily true as there might have been an inconsistency > between the host and the router (caused by more than robustness > missed messages). You're right, I did not consider this scenario. I'm glad that the other comments were useful. Regards, Rolland Vida, LIP6 From owner-idmr@cs.ucl.ac.uk Tue Dec 19 16:23:01 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25243 for ; Tue, 19 Dec 2000 16:23:00 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 19 Dec 2000 18:31:55 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 19 Dec 2000 18:31:48 +0000 Received: from ariel.gi.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 19 Dec 2000 18:31:54 +0000 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JXVVT8LNHSF05DRD@GI.COM> for idmr@cs.ucl.ac.uk; Tue, 19 Dec 2000 10:31:47 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 10:30:16 -0500 Content-return: allowed Date: Tue, 19 Dec 2000 13:33:23 -0500 From: "Nakanishi, Greg" Subject: Question about igmpCacheStatus object in IGMP MIB To: idmr@cs.ucl.ac.uk, "'kzm@cisco.com'" , "'dino@procket.com'" , "'dthaler@microsoft.com'" Message-id: <97DEDE66B3DCD11199D200805FA71BE203BD745C@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Could someone elaborate on the use of the igmpCacheStatus object in the IGMP MIB. The igmpCacheStatus object has an access of read-create. Is the intent to be able to statically provision multicast groups? What should happen if this entry is deleted for a dynamically created multicast group? It seems to me that a subsequent membership report would simply recreated the entry - probably not the desired behavior. Is there a way through the IGMP MIB to control which multicast groups are allowed? thanks, greg From owner-idmr@cs.ucl.ac.uk Wed Dec 20 20:57:21 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21679 for ; Wed, 20 Dec 2000 20:57:19 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 20 Dec 2000 23:52:14 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 20 Dec 2000 23:52:07 +0000 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 20 Dec 2000 23:52:15 +0000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 10E644CE80; Wed, 20 Dec 2000 18:52:14 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA10051; Wed, 20 Dec 2000 18:52:13 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA19099; Wed, 20 Dec 2000 15:52:12 -0800 (PST) Message-Id: <200012202352.PAA19099@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: gnakanishi@gi.com Subject: Re: Question about igmpCacheStatus object in IGMP MIB Cc: idmr@cs.ucl.ac.uk, kzm@cisco.com, dino@procket.com, dthaler@microsoft.com Date: Wed, 20 Dec 2000 15:52:11 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Greg, Creation of rows in the igmpCacheTable is meant to allow management stations to cause managed systems to join groups. (Note objects in igmpBaseMIBGroup vs. igmpRouterMIBGroup). The behavior when deleting rows that were created by a router performing the IGMP protocol is undefined; the agent could refuse to delete the row or allow it to be recreated. Bill From owner-idmr@cs.ucl.ac.uk Tue Dec 26 11:05:08 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19951 for ; Tue, 26 Dec 2000 11:05:07 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 26 Dec 2000 13:32:44 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 25 Dec 2000 12:58:09 +0000 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 25 Dec 2000 12:58:10 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id NAA07862 for ; Mon, 25 Dec 2000 13:58:07 +0100 (MET) Message-ID: <3A47445F.8C9A4729@irisa.fr> Date: Mon, 25 Dec 2000 13:58:07 +0100 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk Subject: IGMPv3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I am reading the igmpv3 : In the draft , they are saying for the interface state: if *any* such record has a filter mode of EXCLUDE, then the filter mode of the interface record is EXCLUDE, and the source list of the interface record is the intersection of the source lists of all socket records in EXCLUDE mode, minus those source addresses that appear in any socket record in INCLUDE mode. For example, if the socket records for multicast address m on interface i are: from socket s1: ( i, m, EXCLUDE, {a, b, c, d} ) from socket s2: ( i, m, EXCLUDE, {b, c, d, e} ) from socket s3: ( i, m, INCLUDE, {d, e, f} ) then the corresponding interface record on interface i is: ( m, EXCLUDE, {b, c} ) But in this case how can : ( m, EXCLUDE, {b, c} ) represents the interface ???? From owner-idmr@cs.ucl.ac.uk Wed Dec 27 08:25:43 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16951 for ; Wed, 27 Dec 2000 08:25:43 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 27 Dec 2000 11:29:11 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 27 Dec 2000 11:29:03 +0000 Received: from suraksha.wipsys.soft.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 27 Dec 2000 11:29:10 +0000 Received: by suraksha.wipro.com (8.8.8+Sun/SMI-SVR4) id QAA25194; Wed, 27 Dec 2000 16:54:42 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma025188; Wed, 27 Dec 00 16:54:34 +0530 Received: from wipro.com ([192.168.162.124]) by bhairavi.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA5E89 for ; Wed, 27 Dec 2000 16:50:17 +0530 Message-ID: <3A49D627.E410E416@wipro.com> Date: Wed, 27 Dec 2000 17:14:39 +0530 From: Vijay Anand Chandrasekar Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "idmr@cs.ucl.ac.uk" Subject: Handling Looped back packets Content-Type: multipart/mixed; boundary="------------10F1958E44DB5990A86542BB" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This is a multi-part message in MIME format. --------------10F1958E44DB5990A86542BB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, Should loop back be enabled on Multicast routers. If so, when we send out a multicast packet, should it be looped back via the loop-back interface. If it is looped back, then looping back forwarded datagrams can cause problems, so at what level should the looped back packet be discarded or how else can it be handled. Thanks in advance Regards, Vijay --------------10F1958E44DB5990A86542BB Content-Type: text/x-vcard; charset=us-ascii; name="vijay.chand.vcf" Content-Description: Card for Vijayanand C Content-Disposition: attachment; filename="vijay.chand.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:;C.Vijayanand tel;work:2301530 - Ext: 343 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:vijay.chand@wipro.com fn:C.Vijayanand end:vcard --------------10F1958E44DB5990A86542BB--