RE: [pim] To support PIM SSM, is there any change to the source = application?

From pim-bounces@ietf.org Tue Jan 03 02:28:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etgai-0007r9-51; Tue, 03 Jan 2006 02:28:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etgag-0007r4-G0 for pim@megatron.ietf.org; Tue, 03 Jan 2006 02:28:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13702 for ; Tue, 3 Jan 2006 02:27:03 -0500 (EST) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etgft-0007pk-Nu for pim@ietf.org; Tue, 03 Jan 2006 02:33:43 -0500 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 02 Jan 2006 23:28:08 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,324,1131350400"; d="scan'208,217"; a="520410013:sNHT42552524" Received: from lepton.jnpr.net ([10.208.0.16]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jan 2006 23:28:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jan 2006 15:27:59 +0800 Message-ID: Thread-Topic: To support PIM SSM, is there any change to the source application? Thread-Index: AcYQNzku4GWE0jOrSZa90Z+tFOyooA== From: "fei wang" To: X-OriginalArrivalTime: 03 Jan 2006 07:28:07.0196 (UTC) FILETIME=[3DC145C0:01C61037] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [pim] To support PIM SSM, is there any change to the source application? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1935074578==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org This is a multi-part message in MIME format. --===============1935074578== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61037.3AB1B342" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61037.3AB1B342 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PIM SSM: If the only change to source is that limit the destination IP range to 232.x.x.x ? =20 Thanks, Fei ------_=_NextPart_001_01C61037.3AB1B342 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

PIM SSM:

If the only change to source is that limit the destination IP range to 232.x.x.x ?

Thanks,

Fei

------_=_NextPart_001_01C61037.3AB1B342-- --===============1935074578== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============1935074578==-- From pim-bounces@ietf.org Tue Jan 03 02:32:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etges-0001la-RF; Tue, 03 Jan 2006 02:32:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etger-0001lT-4c for pim@megatron.ietf.org; Tue, 03 Jan 2006 02:32:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13999 for ; Tue, 3 Jan 2006 02:31:24 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etgk4-0007xC-Mr for pim@ietf.org; Tue, 03 Jan 2006 02:38:02 -0500 Received: from tyholt-ng.uninett.no (tyholt-ng.uninett.no [IPv6:2001:700:1::eecb]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id k037WNe9031354; Tue, 3 Jan 2006 08:32:23 +0100 Date: Tue, 3 Jan 2006 08:32:23 +0100 From: Stig Venaas To: fei wang Subject: Re: [pim] To support PIM SSM, is there any change to the source application? Message-ID: <20060103073222.GB10971@tyholt.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org On Tue, Jan 03, 2006 at 03:27:59PM +0800, fei wang wrote: > PIM SSM: > > If the only change to source is that limit the destination IP range to > 232.x.x.x ? Yes, Stig > > > > Thanks, > > Fei > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jan 03 02:45:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtgrZ-0008Hh-FE; Tue, 03 Jan 2006 02:45:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtgrX-0008HZ-Pb for pim@megatron.ietf.org; Tue, 03 Jan 2006 02:45:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15246 for ; Tue, 3 Jan 2006 02:44:30 -0500 (EST) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etgwl-0008Mq-As for pim@ietf.org; Tue, 03 Jan 2006 02:51:08 -0500 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 02 Jan 2006 23:45:34 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,324,1131350400"; d="scan'208,217"; a="520412071:sNHT41432064" Received: from lepton.jnpr.net ([10.208.0.16]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jan 2006 23:45:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [pim] To support PIM SSM, is there any change to the source application? Date: Tue, 3 Jan 2006 15:45:24 +0800 Message-ID: Thread-Topic: [pim] To support PIM SSM, is there any change to the source application? Thread-Index: AcYQN+el7srDoVP4QXu1ceKjJ5Of4gAAW64g From: "fei wang" To: "Stig Venaas" X-OriginalArrivalTime: 03 Jan 2006 07:45:32.0820 (UTC) FILETIME=[ACFED540:01C61039] X-Spam-Score: 0.3 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1200074070==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org This is a multi-part message in MIME format. --===============1200074070== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61039.A9E42D30" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61039.A9E42D30 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Thanks, Stig. Furthermore, do you know is there any free tool on Linux or Windows to = send IGMP v3 packets? --Fei -----Original Message----- From: Stig Venaas [mailto:Stig.Venaas@uninett.no]=20 Sent: 2006=C4=EA1=D4=C23=C8=D5 15:32 To: fei wang Cc: pim@ietf.org Subject: Re: [pim] To support PIM SSM, is there any change to the source = application? On Tue, Jan 03, 2006 at 03:27:59PM +0800, fei wang wrote: > PIM SSM: >=20 > If the only change to source is that limit the destination IP range to > 232.x.x.x ? Yes, Stig >=20 > =20 >=20 > Thanks, >=20 > Fei >=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim ------_=_NextPart_001_01C61039.A9E42D30 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable RE: [pim] To support PIM SSM, is there any change to the source = application?

Thanks, Stig.

Furthermore, do you know is there any free tool on Linux or = Windows to send IGMP v3 packets?

--Fei

-----Original Message-----
From: Stig Venaas [mailto:Stig.Venaas@uninett.no]=
Sent: 2006=C4=EA1=D4=C23=C8=D5 15:32
To: fei wang
Cc: pim@ietf.org
Subject: Re: [pim] To support PIM SSM, is there any change = to the source application?

On Tue, Jan 03, 2006 at 03:27:59PM +0800, fei wang = wrote:

> PIM SSM:

> If the only change to source is that limit = the destination IP range to

> 232.x.x.x ?

Yes,

Stig

> Thanks,

> Fei

> = _______________________________________________

> pim mailing list

> pim@ietf.org

> https://www1.ietf.org= /mailman/listinfo/pim

------_=_NextPart_001_01C61039.A9E42D30-- --===============1200074070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============1200074070==-- From pim-bounces@ietf.org Tue Jan 03 05:05:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etj2b-00025n-O2; Tue, 03 Jan 2006 05:05:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etj2Z-00025g-ES for pim@megatron.ietf.org; Tue, 03 Jan 2006 05:05:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01096 for ; Tue, 3 Jan 2006 05:04:01 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etj7l-0004sA-TD for pim@ietf.org; Tue, 03 Jan 2006 05:10:41 -0500 Received: from tyholt-ng.uninett.no (tyholt-ng.uninett.no [IPv6:2001:700:1::eecb]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id k03A4ve9030176; Tue, 3 Jan 2006 11:04:57 +0100 Date: Tue, 3 Jan 2006 11:04:57 +0100 From: Stig Venaas To: fei wang Subject: Re: [pim] To support PIM SSM, is there any change to the source application? Message-ID: <20060103100457.GA16237@tyholt.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org On Tue, Jan 03, 2006 at 03:45:24PM +0800, fei wang wrote: > > Thanks, Stig. > > Furthermore, do you know is there any free tool on Linux or Windows to send IGMP v3 packets? Not that I know, but you can of course have an application join/leave SSM channels, and let the operating system generate and send IGMPv3. I'm wondering if anyone has implemented any IGMP proxying for Linux, I would like to know if anyone has. If IGMPv3 proxying is done, the code could be of use to you as well. Stig _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jan 03 05:13:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtjAn-0004RH-Ep; Tue, 03 Jan 2006 05:13:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtjAl-0004R9-1O for pim@megatron.ietf.org; Tue, 03 Jan 2006 05:13:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02101 for ; Tue, 3 Jan 2006 05:12:29 -0500 (EST) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtjFz-00057K-7C for pim@ietf.org; Tue, 03 Jan 2006 05:19:09 -0500 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by borg.juniper.net with ESMTP; 03 Jan 2006 02:13:31 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,325,1131350400"; d="scan'208,217"; a="520429287:sNHT45852350" Received: from lepton.jnpr.net ([10.208.0.16]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jan 2006 02:13:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [pim] Are there any freeware tools which support IGMPv3 host stack Date: Tue, 3 Jan 2006 18:13:24 +0800 Message-ID: Thread-Topic: [pim] Are there any freeware tools which support IGMPv3 host stack Thread-Index: AcXvJNhgFp+QYnC4S62r6Fxhjqo/mAhKGrLA From: "fei wang" To: X-OriginalArrivalTime: 03 Jan 2006 10:13:29.0866 (UTC) FILETIME=[58208EA0:01C6104E] X-Spam-Score: 0.4 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0014011188==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org This is a multi-part message in MIME format. --===============0014011188== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6104E.54E5BE08" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6104E.54E5BE08 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable =20 =20 =20 -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of = Sowmya.Krishnaswamy@nokia.com Sent: 2005=C4=EA11=D4=C222=C8=D5 13:23 To: pim@ietf.org Subject: [pim] Are there any freeware tools which support IGMPv3 host = stack =20 Hello,=20 =20 Are there any freeware tools that run the IGMPv3 host stack (sending INCLUDE and EXCLUDE membership reports) which can be used for testing IGMPv3 querier state machine.=20 =20 VLC (video lan client) is one such freeware tool with supports v3 host stack. VLC generates INCLUDE reports when configured to listen to traffic only from certain selected sources. Is there is a way to configure VLC to EXCLUDE traffic from certain sources.=20 =20 [fei wang] I captured the IGMP packet by executing the =A1=AEvlc = udp:10.208.5.5@232.34.56.78=A1=AF command on XP. It seemed that the VLC only send IGMPv3 Packet with Record Type 5 (Allow = new Source) other than type 1. And when I stop the multicasting by = clicking the =A1=AEStop=A1=AF button on the panel, the Type 6 (Block Old = Sources) message was sent. =20 I think a special tool to simulate all type of IGMPv3 message was badly = needed. =20 Cisco 12.4 seems to support v3 host stack. The command to send membership reports with INCLUDE records seems fairly simple. Cisco supports "join igmp X1.X2.X3.X4 source Y1.Y2.Y3.Y4". How do we get the Cisco box to send reports with EXCLUDE records. =20 Thanks, Sowmya =20 _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim ------_=_NextPart_001_01C6104E.54E5BE08 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

-----Original Message-----
From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of = Sowmya.Krishnaswamy@nokia.com
Sent: 2005=C4=EA11=D4=C222=C8=D5 13:23
To: pim@ietf.org
Subject: [pim] Are there any freeware tools which support IGMPv3 host = stack

Hello,

Are there any freeware tools that run the IGMPv3 host stack = (sending

INCLUDE and EXCLUDE membership reports) which can be used for = testing

IGMPv3 querier state machine.

VLC (video lan client) is one such freeware tool with supports v3 = host

stack. VLC generates INCLUDE reports when configured to listen = to

traffic only from certain selected sources. Is there is a way = to

configure VLC to EXCLUDE traffic from certain sources. =

= [fei wang] I captured the = IGMP packet by executing the =A1=AEvlc udp:10.208.5.5@232.34.56.78=A1=AF = command on XP.

= It seemed that the VLC only send IGMPv3 Packet with Record Type 5 (Allow = new Source) other than type 1. And when I stop the multicasting by clicking = the =A1=AEStop=A1=AF button on the panel, the Type 6 (Block Old Sources) message was = sent.

= I think a special tool to simulate all type of IGMPv3 message was badly = needed.

Cisco 12.4 seems to support v3 host stack. The command to = send

membership reports with INCLUDE records seems fairly simple. = Cisco

supports "join igmp X1.X2.X3.X4 source Y1.Y2.Y3.Y4". = How do we get the

Cisco box to send reports with EXCLUDE = records.

Thanks,

Sowmya

_______________________________________________<= /font>

pim mailing list

pim@ietf.org

https://www1.ietf.org/mailman/listinfo/pim

------_=_NextPart_001_01C6104E.54E5BE08-- --===============0014011188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============0014011188==-- From pim-bounces@ietf.org Tue Jan 03 08:17:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etm2g-0002Xm-QQ; Tue, 03 Jan 2006 08:17:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etm2d-0002Xe-Qx for pim@megatron.ietf.org; Tue, 03 Jan 2006 08:17:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22316 for ; Tue, 3 Jan 2006 08:16:16 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etm7v-0002dV-3t for pim@ietf.org; Tue, 03 Jan 2006 08:22:59 -0500 Received: from tyholt-ng.uninett.no (tyholt-ng.uninett.no [IPv6:2001:700:1::eecb]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id k03DHKe9001476; Tue, 3 Jan 2006 14:17:20 +0100 Date: Tue, 3 Jan 2006 14:17:20 +0100 From: Stig Venaas To: fei wang Subject: Re: [pim] Are there any freeware tools which support IGMPv3 host stack Message-ID: <20060103131720.GA14441@tyholt.uninett.no> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: pim@ietf.org, Sowmya.Krishnaswamy@nokia.com X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 03, 2006 at 06:13:24PM +0800, fei wang wrote: > Are there any freeware tools that run the IGMPv3 host stack (sending > > INCLUDE and EXCLUDE membership reports) which can be used for testing > > IGMPv3 querier state machine. > > > > VLC (video lan client) is one such freeware tool with supports v3 host > > stack. VLC generates INCLUDE reports when configured to listen to > > traffic only from certain selected sources. Is there is a way to > > configure VLC to EXCLUDE traffic from certain sources. See the attached source for a tool called mctest that I wrote. All it does, is join a list of sources for a group (INCLUDE), or join a group and exclude a number of sources. You can then look at the IGMP reports sent by the system. Stig --ZGiS0Q5IWpPtfppv Content-Type: text/x-csrc; charset=us-ascii Content-Disposition: attachment; filename="mctest.c" /* Stig Venaas * 2004.09.21 */ #include #include #include #include #include #include #include #include #include #include #include #include #include #ifndef IP_ADD_SOURCE_MEMBERSHIP struct ip_mreq_source { struct in_addr imr_multiaddr; /* IP address of group */ struct in_addr imr_interface; /* IP address of interface */ struct in_addr imr_sourceaddr; /* IP address of source */ }; #define IP_ADD_SOURCE_MEMBERSHIP 39 #define IP_DROP_SOURCE_MEMBERSHIP 40 #endif #ifndef MCAST_JOIN_GROUP struct group_req { uint32_t gr_interface; /* interface index */ struct sockaddr_storage gr_group; /* group address */ }; #define MCAST_JOIN_GROUP 42 #endif #ifndef MCAST_BLOCK_SOURCE #define MCAST_BLOCK_SOURCE 43 #define MCAST_UNBLOCK_SOURCE 44 #endif #ifndef MCAST_LEAVE_GROUP #define MCAST_LEAVE_GROUP 45 #endif #ifndef MCAST_JOIN_SOURCE_GROUP struct group_source_req { uint32_t gsr_interface; /* interface index */ struct sockaddr_storage gsr_group; /* group address */ struct sockaddr_storage gsr_source; /* source address */ }; #define MCAST_JOIN_SOURCE_GROUP 46 #define MCAST_LEAVE_SOURCE_GROUP 47 #endif #ifndef MCAST_EXCLUDE #define MCAST_EXCLUDE 0 #endif #ifndef MCAST_INCLUDE #define MCAST_INCLUDE 1 #endif #ifndef HAVE_SETSOURCEFILTER int setsourcefilter(int s, uint32_t interface, struct sockaddr *group, socklen_t grouplen, /* RFC 3678 says numsrc is uint_t! */ uint32_t fmode, uint32_t numsrc, struct sockaddr_storage *slist) { struct group_req greq; struct group_source_req gsreq; int slevel, sopt, i; slevel = group->sa_family == AF_INET ? IPPROTO_IP : IPPROTO_IPV6; if (!numsrc || fmode == MCAST_EXCLUDE) { /* should we allow numsrc == 0? */ /* do we need to join group before blocking sources? */ greq.gr_interface = interface; memcpy(&greq.gr_group, group, grouplen); if (setsockopt(s, slevel, MCAST_JOIN_GROUP, (char *)&greq, sizeof(greq)) < 0) return -1; if (!numsrc) return 0; } /* do we really need to set interface when blocking? Can you join group on multiple interfaces and block different sources? */ gsreq.gsr_interface = interface; memcpy(&gsreq.gsr_group, group, grouplen); sopt = fmode == MCAST_EXCLUDE ? MCAST_BLOCK_SOURCE : MCAST_JOIN_SOURCE_GROUP; for (i = 0; i < numsrc; i++) { gsreq.gsr_source = slist[i]; if (setsockopt(s, slevel, sopt, (char *)&gsreq, sizeof(gsreq)) < 0) { /* We should clean up. When blocking, enough to leave group, or unblock sources also? */ return -1; } } return 0; } #endif extern int errno; extern int optind; extern char *optarg; void usage() { fprintf(stderr, "Usage:\tmctest -t [-options] multicast-group [ < in ]\n"); fprintf(stderr, "\tmctest -r [-options] multicast-group [ > out]\n"); fprintf(stderr, "Common options:\n"); fprintf(stderr, "\t-p ## port number to send to or listen at (default 5001)\n"); fprintf(stderr, "Options specific to -t:\n"); fprintf(stderr, "\t-w ## number of microseconds to wait between each write\n"); fprintf(stderr, "Options specific to -r:\n"); fprintf(stderr, "\t-I if specify the network interface (e.g. eth0) to use\n"); exit(1); }; void err(char *s) { fprintf(stderr,"mctest: "); perror(s); fprintf(stderr, "errno=%d\n", errno); exit(1); } int addrlist_pton(struct sockaddr_storage **nal, char *pal) { char *s, *t; int i, n, e; struct addrinfo hints, *res; printf("0:%s\n",pal); if (!pal) return 0; /* find number of addresses */ for (n=1, s = pal; *s; s++) if (*s == ',') n++; *nal = malloc(n * sizeof(struct sockaddr_storage)); if (!*nal) return 0; memset(&hints, '\0', sizeof(hints)); hints.ai_family = AF_UNSPEC; for (i = 0, s = pal;; i++) { printf("1:%s\n",s); t = strchr(s, ','); if (t) *t = '\0'; if ((e = getaddrinfo(s, NULL, &hints, &res))) { fprintf(stderr, "getaddrinfo failed: %s\n", gai_strerror(n)); free(*nal); return 0; } /* We only use first value, a name might resolve to multiple */ memcpy(*nal+i, res->ai_addr, res->ai_addrlen); freeaddrinfo(res); if (!t) break; s = t + 1; } return n; } int mcaddr(struct sockaddr_storage *ss) { switch (((struct sockaddr *)ss)->sa_family) { case AF_INET: return IN_MULTICAST(ntohl(((struct sockaddr_in *)ss)->sin_addr.s_addr)); case AF_INET6: return IN6_IS_ADDR_MULTICAST(&((struct sockaddr_in6 *)ss)->sin6_addr); } return 0; } int main(int argc, char **argv) { int c; int trans; char *port = "5001"; static long wait = 0; /* usecs to wait between each write */ char *ifname = NULL; struct sockaddr_storage *addrlist, *slist; struct sockaddr *group; socklen_t grouplen; int naddr, nsrc; int fmode; int s; /* struct sockaddr_storage frominet; struct addrinfo hints, *res, *res0; struct ipv6_mreq mreq6; struct ip_mreq mreq; int one = 1; int af = AF_UNSPEC; */ /* Address family to be determined */ if (argc < 2) usage(); while ((c = getopt(argc, argv, "rtp:w:I:")) != -1) { switch (c) { case 'r': trans = 0; break; case 't': trans = 1; break; case 'p': port = optarg; break; case 'w': wait = strtol(optarg, (char **)NULL, 10); break; case 'I': ifname = optarg; break; default: usage(); } } if (optind + 1 != argc) usage(); naddr = addrlist_pton(&addrlist, argv[optind]); if (naddr == 0) err("No valid names or addresses specified"); nsrc = naddr - 1; if (mcaddr(addrlist)) { fmode = MCAST_EXCLUDE; group = (struct sockaddr *)addrlist; slist = nsrc ? addrlist + 1 : NULL; } else if (mcaddr(addrlist + nsrc)) { fmode = MCAST_INCLUDE; group = (struct sockaddr *)(addrlist + nsrc); slist = addrlist; } else err("First or last address must be a multicast address\n"); grouplen = group->sa_family == AF_INET ? sizeof(struct sockaddr_in) : sizeof(struct sockaddr_in6); if ((s = socket(group->sa_family, SOCK_DGRAM, 0)) < 0) err("socket"); if (setsourcefilter(s, ifname ? if_nametoindex(ifname) : 0, group, grouplen, fmode, nsrc, slist) < 0) err("setsourcefilter"); sleep(600); return 0; } --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --ZGiS0Q5IWpPtfppv-- From pim-bounces@ietf.org Tue Jan 03 14:20:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etrhi-0001ia-5x; Tue, 03 Jan 2006 14:20:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etrhg-0001i2-RX for pim@megatron.ietf.org; Tue, 03 Jan 2006 14:20:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15079 for ; Tue, 3 Jan 2006 14:19:01 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etrmz-0007yp-SN for pim@ietf.org; Tue, 03 Jan 2006 14:25:48 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 03 Jan 2006 11:20:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k03JK3YY013068 for ; Tue, 3 Jan 2006 11:20:05 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Jan 2006 11:20:04 -0800 Received: from irp-view6.cisco.com ([171.70.65.143]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Jan 2006 11:20:04 -0800 Date: Tue, 3 Jan 2006 11:20:04 -0800 (PST) From: Mike McBride To: pim@ietf.org Subject: [pim] WG Last Call - draft-ietf-pim-join-attributes-00 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 03 Jan 2006 19:20:04.0703 (UTC) FILETIME=[B35F8EF0:01C6109A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Today begins a 2 week working group last call for the pim-join-attributes draft. January 17th, 2006 will be the final day of the last call. Please review this document and send any comments to the list. http://www.ietf.org/internet-drafts/draft-ietf-pim-join-attributes-00.txt thanks, mike _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Jan 04 21:28:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuKrV-00034m-Iu; Wed, 04 Jan 2006 21:28:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuKrT-00034d-Kh for pim@megatron.ietf.org; Wed, 04 Jan 2006 21:28:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07167 for ; Wed, 4 Jan 2006 21:27:03 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuKx3-0005U0-Kl for pim@ietf.org; Wed, 04 Jan 2006 21:34:07 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2006 18:22:54 -0800 X-IronPort-AV: i="3.99,331,1131350400"; d="scan'208"; a="387487752:sNHT98054961318" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k052MrQi015407; Wed, 4 Jan 2006 18:22:54 -0800 (PST) Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 18:22:53 -0800 Received: from [192.168.1.136] ([10.21.90.209]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 18:22:53 -0800 In-Reply-To: <20060103100457.GA16237@tyholt.uninett.no> References: <20060103100457.GA16237@tyholt.uninett.no> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <188CB62E-8195-40E1-9E83-B3B74D9A18CF@cisco.com> Content-Transfer-Encoding: 7bit From: John Zwiebel Subject: Re: [pim] To support PIM SSM, is there any change to the source application? Date: Wed, 4 Jan 2006 18:23:18 -0800 To: Stig Venaas X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Jan 2006 02:22:53.0303 (UTC) FILETIME=[EEA67870:01C6119E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Windows XP supports IGMPv3 and the app "pmsft" can be used to send the appropriate commands messages. On Jan 3, 2006, at 2:04 AM, Stig Venaas wrote: > On Tue, Jan 03, 2006 at 03:45:24PM +0800, fei wang wrote: >> >> Thanks, Stig. >> >> Furthermore, do you know is there any free tool on Linux or >> Windows to send IGMP v3 packets? > > Not that I know, but you can of course have an application join/leave > SSM channels, and let the operating system generate and send IGMPv3. > > I'm wondering if anyone has implemented any IGMP proxying for Linux, I > would like to know if anyone has. If IGMPv3 proxying is done, the code > could be of use to you as well. > > Stig > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Jan 04 22:50:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuM93-0002vI-SC; Wed, 04 Jan 2006 22:50:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuM90-0002v9-0M for pim@megatron.ietf.org; Wed, 04 Jan 2006 22:50:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14375 for ; Wed, 4 Jan 2006 22:49:14 -0500 (EST) Received: from sfovwl03.progeon.com ([216.251.50.9] helo=SFOVWL03.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuMEa-0007y2-88 for pim@ietf.org; Wed, 04 Jan 2006 22:56:17 -0500 Received: from INDHUBBHS02.ad.infosys.com ([192.168.200.82]) by SFOVWL03.infosys.com with InterScan Messaging Security Suite; Wed, 04 Jan 2006 19:44:54 -0800 Received: from BLRKECMSG04.ad.infosys.com ([172.25.213.134]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Jan 2006 09:18:18 +0530 Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by BLRKECMSG04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 09:18:18 +0530 Received: from osfr-173.local ([192.168.101.134]) by BLRKECMSG01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 09:18:18 +0530 From: Bharat Joshi To: pim@ietf.org Content-Type: text/plain Organization: Infosys Technologies Ltd Date: Thu, 05 Jan 2006 09:18:13 +0530 Message-Id: <1136432893.13599.7.camel@magadha> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jan 2006 03:48:18.0498 (UTC) FILETIME=[DD812A20:01C611AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Subject: [pim] Some questions on join-attributed draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Hi, I have couple of questions: * Can we rephrase the following statement in section 2.2: "forward the attributes regardless if they understand the TLV's encoded in the attribute not." to forward the attributes regardless of whether they understand the TLV's encoded in the attribute or not. * In section 2.2, the document says: "If this bit is set then the TLV is forwarded upstream in case the router does not understand that type." This seems to be conflicting with what is mentioned just above this statement. In the first statement, document mention to have a way to forward TLV to upstream regardless of whether a router understands it and in this statement we say that router will forward it when router does not understand it. * In section 2.6, the document says: "Attributes not processed are passed upstream unchanged.". Is this done based on the bit defined in section 2.2 or regardless of that bit, these TLVs are forwarded to upstream? * In section 3.1, there is no length field in source encoding type so how does a router will know that there are any TLVs after the source address? * There is no section about the "Security Consideration" in the document. Thanks & 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*** _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Jan 05 01:16:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuOQW-0008AE-7F; Thu, 05 Jan 2006 01:16:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuOQT-00089U-Cs for pim@megatron.ietf.org; Thu, 05 Jan 2006 01:16:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28403 for ; Thu, 5 Jan 2006 01:15:25 -0500 (EST) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuOW6-0004au-4p for pim@ietf.org; Thu, 05 Jan 2006 01:22:30 -0500 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 04 Jan 2006 22:16:32 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,331,1131350400"; d="scan'208,217"; a="520807945:sNHT42563024" Received: from lepton.jnpr.net ([10.208.0.16]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 22:16:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Jan 2006 14:16:27 +0800 Message-ID: Thread-Topic: When will the IGMPv3 type 6 Group record be sent by IPTV end users? Thread-Index: AcYRv4+dR/IHJiDTTjiuTdB3dz9hxQ== From: "fei wang" To: X-OriginalArrivalTime: 05 Jan 2006 06:16:30.0987 (UTC) FILETIME=[91D74DB0:01C611BF] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: Stig Venaas Subject: [pim] When will the IGMPv3 type 6 Group record be sent by IPTV end users? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2014660235==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org This is a multi-part message in MIME format. --===============2014660235== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C611BF.8FE63010" This is a multi-part message in MIME format. ------_=_NextPart_001_01C611BF.8FE63010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let's suppose an IPTV deployment scenario. =20 There have two TV station TVs1 and TVs2 which may correspond to two multicast Sources in PIM. And multiple channels associated with each TV station which may correspond to multicast Group in PIM. =20 And normally the user do a channel zapping, which may result in the type6 BLOCK_OLD_SOURCES( TVs1, G1 ) and type5 ALLOW_NEW_SOURCE( TVs2, G2) sending. I am wondering, for one Group when will the end user device (STB or PC) send such Source-List-Change records? Since the same multicast Group could NOT be owned by two Sources (TV station in IPTV).=20 =20 Since the IGMPV3 RFC define the detail Query and Response behavior for the Source-List-Change record towards one Group, any scenario will fulfill the rule? And rather, the IGMPv3 is designed to maintain the one-multiple (one group vs. multiple sources) relationship, however for the IPVT, in many cases, it use one Source (TV station) vs. Multiple Group (channel) model. Any one can explain the difference from the realistic applications (besides IPTV)?=20 =20 Regards, =20 Fei ------_=_NextPart_001_01C611BF.8FE63010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let’s suppose an IPTV deployment = scenario.

There have two TV station TVs1 and TVs2 which = may correspond to two multicast Sources in PIM. And multiple channels = associated with each TV station which may correspond to multicast Group in = PIM.

And normally the user do a channel zapping, = which may result in the type6 BLOCK_OLD_SOURCES( TVs1, G1 ) and type5 ALLOW_NEW_SOURCE( = TVs2, G2) sending. I am wondering, for one Group when will the end user device = (STB or PC) send such Source-List-Change records? Since the same multicast = Group could NOT be owned by two Sources (TV station in IPTV). =

Since the IGMPV3 RFC define the detail Query = and Response behavior for the Source-List-Change record towards one Group, = any scenario will fulfill the rule? And rather, the IGMPv3 is designed to maintain = the one-multiple (one group vs. multiple sources) relationship, however for = the IPVT, in many cases, it use one Source (TV station) vs. Multiple Group = (channel) model. Any one can explain the difference from the realistic = applications (besides IPTV)?

Regards,

Fei

------_=_NextPart_001_01C611BF.8FE63010-- --===============2014660235== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============2014660235==-- From pim-bounces@ietf.org Thu Jan 05 06:07:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuSxr-0004YW-Cy; Thu, 05 Jan 2006 06:07:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuSxo-0004Y7-Ng for pim@megatron.ietf.org; Thu, 05 Jan 2006 06:07:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26965 for ; Thu, 5 Jan 2006 06:06:09 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuT3T-0005Sz-V4 for pim@ietf.org; Thu, 05 Jan 2006 06:13:16 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 05 Jan 2006 02:38:31 -0800 X-IronPort-AV: i="3.99,333,1131350400"; d="scan'208"; a="387615626:sNHT2310025862" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k05AcUWF005081; Thu, 5 Jan 2006 02:38:30 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA00219; Thu, 5 Jan 2006 02:38:30 -0800 (PST) Date: Thu, 5 Jan 2006 02:38:30 -0800 From: Toerless Eckert To: fei wang Subject: Re: [pim] When will the IGMPv3 type 6 Group record be sent by IPTV end users? Message-ID: <20060105103829.GO2301@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Stig Venaas , pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Fei, I'm not quite clear what your question is. Check out the SSM architecture draft. In traditional "ASM" (Any Source Multicast), a host "joins to a group", which is basically what you could do in IGMPv1 and IGPv2. In IGMPv3, that would be an EXCLUDE({}, G) membership. In SSM, the host "subscribes to a channel" (S,G), which is only possible with IGMPV3 via an INCLUDE({S},G) membership. If you talk about such INCLUDE({S},G) memberships, then this is always SSM, and if you have two channels, then they could use the same group, eg: (S1,G) = TV-program-1 and (S2,G) = TV-program-2, or they could use different groups, eg: (S1,G1) = TV-program-1 and (S2,G2) = TV-program-2. There is no architecture reason win SM hy two TV-programs should have different groups, but thee are some short-term deployment reasons: a) When users migrate from ASM to SSM, some transition methods (like SSM Mapping) still require for different programs to use different groups. b) When using an L2 switched access network with IGMP snooping, man current IGMP snoopingswitches can suport IGMPv3 snooping, but can not separate in the forwarding plane forwarding for (S1,G) and (S2,G) because their L2 forwarding isonly based on MAC(G). Whether or not a single IGMPv3 packet would ever contain the wo type6 message elements is a question of the host-stack implementation. I would bet that any implementation, eg: in a Set-Top-Box would most likely send two separate packets, one for the TV-program-1 "unsubscribe" (BLOCK_OLD_SOURCE) and another packet for the "subscribe" of the new TV-program (ALLOW_NEW_SOURCE). The reason is that the TV-application wil likely use the MSF-PI towards the (STB's) OS, and that has two different calls for these actions, and the most common OS implementation of IGMPv3 wil not try to batch multiple API cals for such triggerent membership changes. But it would of course be a nice optimization to put both requests into the same packet. Does this answer your questions ? Cheers Toerless On Thu, Jan 05, 2006 at 02:16:27PM +0800, fei wang wrote: > Let's suppose an IPTV deployment scenario. > > > > There have two TV station TVs1 and TVs2 which may correspond to two > multicast Sources in PIM. And multiple channels associated with each TV > station which may correspond to multicast Group in PIM. > > > > And normally the user do a channel zapping, which may result in the > type6 BLOCK_OLD_SOURCES( TVs1, G1 ) and type5 ALLOW_NEW_SOURCE( TVs2, > G2) sending. I am wondering, for one Group when will the end user device > (STB or PC) send such Source-List-Change records? Since the same > multicast Group could NOT be owned by two Sources (TV station in IPTV). > > > > Since the IGMPV3 RFC define the detail Query and Response behavior for > the Source-List-Change record towards one Group, any scenario will > fulfill the rule? And rather, the IGMPv3 is designed to maintain the > one-multiple (one group vs. multiple sources) relationship, however for > the IPVT, in many cases, it use one Source (TV station) vs. Multiple > Group (channel) model. Any one can explain the difference from the > realistic applications (besides IPTV)? > > > > Regards, > > > > Fei > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim -- Thanks Toerless Eckert _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Jan 05 11:35:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuY52-0006uk-RT; Thu, 05 Jan 2006 11:35:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuY51-0006uf-L1 for pim@megatron.ietf.org; Thu, 05 Jan 2006 11:35:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05769 for ; Thu, 5 Jan 2006 11:33:56 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYAj-0000Yx-65 for pim@ietf.org; Thu, 05 Jan 2006 11:41:06 -0500 Received: by zproxy.gmail.com with SMTP id 9so3102061nzo for ; Thu, 05 Jan 2006 08:35:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QuhvNVlyp30Fw+BEzIu5UzcRh8RCw/D32krIxD2XwVUKDOqLll70Dqap6xZMb+Qh3QUaGXhj6efbWm6wBMujIzApSjO5CR9Fx5gaK2H8gYwsabkje+BhcO6CUAxu8KD7tcT+uqd+/2KdFvoIk9Ak6K0ybtXLrw5C14TAr235u2o= Received: by 10.36.42.4 with SMTP id p4mr6927369nzp; Thu, 05 Jan 2006 08:35:08 -0800 (PST) Received: by 10.36.46.2 with HTTP; Thu, 5 Jan 2006 08:35:08 -0800 (PST) Message-ID: Date: Thu, 5 Jan 2006 11:35:08 -0500 From: Marshall Eubanks To: Toerless Eckert Subject: Re: [pim] When will the IGMPv3 type 6 Group record be sent by IPTV end users? In-Reply-To: <20060105103829.GO2301@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060105103829.GO2301@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Cc: Stig Venaas , pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Hello; On 1/5/06, Toerless Eckert wrote: > Fei, > > I'm not quite clear what your question is. Check out the > SSM architecture draft. In traditional "ASM" (Any Source Multicast), > a host "joins to a group", which is basically what you could do in > IGMPv1 and IGPv2. In IGMPv3, that would be an EXCLUDE({}, G) membership. > In SSM, the host "subscribes to a channel" (S,G), which is only > possible with IGMPV3 via an INCLUDE({S},G) membership. If you talk > about such INCLUDE({S},G) memberships, then this is always SSM, and > if you have two channels, then they could use the same group, eg: > (S1,G) =3D TV-program-1 and (S2,G) =3D TV-program-2, or they could > use different groups, eg: (S1,G1) =3D TV-program-1 and (S2,G2) =3D TV-pro= gram-2. > > There is no architecture reason win SM hy two TV-programs should have > different groups, but thee are some short-term deployment reasons: > a) When users migrate from ASM to SSM, some transition methods > (like SSM Mapping) still require for different programs to use > different groups. > b) When using an L2 switched access network with IGMP snooping, > man current IGMP snoopingswitches can suport IGMPv3 snooping, but > can not separate in the forwarding plane forwarding for (S1,G) > and (S2,G) because their L2 forwarding isonly based on MAC(G). I would add that - PIM snooping switches also may only look at G, not {S,G}. (Others may only look at S.) So, these would have the same problem with sources sharing the same channel numbers. - SSM groups with the same channel will of course map into the same Ethernet MAC address, and thus, if you are on a LAN that floods multicast, or a snooping switch that can't distinguish between them, this may cause problems as the device NIC card will pass both streams up the stack. This will be even worse if they use the same ports. So, I would recommend that SSM channels try and pick unique groups. There are a lot to chose from. > > Whether or not a single IGMPv3 packet would ever contain the wo > type6 message elements is a question of the host-stack implementation. > I would bet that any implementation, eg: in a Set-Top-Box would most > likely send two separate packets, one for the TV-program-1 "unsubscribe" > (BLOCK_OLD_SOURCE) and another packet for the "subscribe" of the > new TV-program (ALLOW_NEW_SOURCE). The reason is that the TV-application > wil likely use the MSF-PI towards the (STB's) OS, and that has two differ= ent > calls for these actions, and the most common OS implementation of > IGMPv3 wil not try to batch multiple API cals for such triggerent > membership changes. But it would of course be a nice optimization > to put both requests into the same packet. > > Does this answer your questions ? > > Cheers > Toerless > > On Thu, Jan 05, 2006 at 02:16:27PM +0800, fei wang wrote: > > Let's suppose an IPTV deployment scenario. > > > > > > > > There have two TV station TVs1 and TVs2 which may correspond to two > > multicast Sources in PIM. And multiple channels associated with each TV > > station which may correspond to multicast Group in PIM. > > > > > > > > And normally the user do a channel zapping, which may result in the > > type6 BLOCK_OLD_SOURCES( TVs1, G1 ) and type5 ALLOW_NEW_SOURCE( TVs2, > > G2) sending. I am wondering, for one Group when will the end user devic= e > > (STB or PC) send such Source-List-Change records? Since the same > > multicast Group could NOT be owned by two Sources (TV station in IPTV). > > Sources do not "own" groups. In ASM, more than one source can send (of course, this may be desired), in SSM each channel is associated with a particular source address. > > > > > > Since the IGMPV3 RFC define the detail Query and Response behavior for > > the Source-List-Change record towards one Group, any scenario will > > fulfill the rule? And rather, the IGMPv3 is designed to maintain the > > one-multiple (one group vs. multiple sources) relationship, however for > > the IPVT, in many cases, it use one Source (TV station) vs. Multiple > > Group (channel) model. Any one can explain the difference from the > > realistic applications (besides IPTV)? > > > > There is nothing in SSM to prevent one source from sourcing many channels, just as there is nothing in ASM to prevent one source to send to many groups. Both are quite routine. Regards Marshall > > > > Regards, > > > > > > > > Fei > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www1.ietf.org/mailman/listinfo/pim > > > -- > Thanks > Toerless Eckert > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jan 09 13:57:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2D2-0004dV-VW; Mon, 09 Jan 2006 13:57:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2D1-0004cm-Ej for pim@megatron.ietf.org; Mon, 09 Jan 2006 13:57:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12098 for ; Mon, 9 Jan 2006 13:56:15 -0500 (EST) Received: from h-83-140-32-156.ip.cust.port80.se ([83.140.32.156] helo=alpha.sajtx.net ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew2JY-00082c-S3 for pim@ietf.org; Mon, 09 Jan 2006 14:04:22 -0500 Received: from localhost (sajtx.net [127.0.0.1]) by alpha.sajtx.net (Postfix) with ESMTP id 985B8988712 for ; Mon, 9 Jan 2006 19:57:09 +0100 (CET) Received: from alpha.sajtx.net ([127.0.0.1]) by localhost (alpha [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12158-10 for ; Mon, 9 Jan 2006 19:57:09 +0100 (CET) Received: from UebiMiau (sajtx.net [127.0.0.1]) by alpha.sajtx.net (Postfix) with SMTP id 1CF05988711 for ; Mon, 9 Jan 2006 19:57:09 +0100 (CET) Received: from client 85.225.115.148 for UebiMiau2.7 (webmail client); Mon, 9 Jan 2006 19:57:09 -0000 Date: Mon, 9 Jan 2006 19:57:09 -0000 From: "Dev" To: pim@ietf.org X-Priority: 3 X-Mailer: UebiMiau 2.7.2 X-Original-IP: 85.225.115.148 X-MSMail-Priority: Medium Importance: Medium MIME-Version: 1.0 Message-Id: <20060109185709.1CF05988711@alpha.sajtx.net> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at sajtx.net X-Spam-Score: 3.1 (+++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [pim] PIM-SM - IP Address of Register messages X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dev List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0562865035==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --===============0562865035== Content-Type: text/html; charset="iso-8859-1"; Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable

Hello

I have a question about the IP address of a register message with multicast payload.

Consider this.
One router with the interfaces IF_A and IF_B. It receives a multicast stream from a directly connected neighbor on IF_A. T= he router has been chosen to be the DR on this interface and encapsulates th= e stream and forwards it onto IF_B, which is in the direction towards the RP.

Now my to my question.
Which is the correct IP source address of t= he Register packet. (The external IP header). Is it IPADDR(IF_A) or IPADDR(IF_B)? Or maybe it doesn't matter?

Best regards
David

--===============0562865035== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============0562865035==-- From pim-bounces@ietf.org Mon Jan 09 14:57:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew38Z-00046x-9K; Mon, 09 Jan 2006 14:57:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew38W-00046p-5Z for pim@megatron.ietf.org; Mon, 09 Jan 2006 14:57:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17521 for ; Mon, 9 Jan 2006 14:55:39 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew3F4-0001VK-4n for pim@ietf.org; Mon, 09 Jan 2006 15:03:46 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 09 Jan 2006 11:56:47 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k09JukQk026379; Mon, 9 Jan 2006 11:56:46 -0800 (PST) Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 11:56:46 -0800 Received: from [171.71.189.235] ([171.71.189.235]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 11:56:45 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: From: John Zwiebel Subject: Re: [pim] When will the IGMPv3 type 6 Group record be sent by IPTV end users? Date: Mon, 9 Jan 2006 11:57:21 -0800 To: "fei wang" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 09 Jan 2006 19:56:45.0645 (UTC) FILETIME=[D1B727D0:01C61556] X-Spam-Score: 0.8 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: Stig Venaas , pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0396502555==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --===============0396502555== Content-Type: multipart/alternative; boundary=Apple-Mail-2--384348681 --Apple-Mail-2--384348681 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable I think the the question you were asking was, "How practical is it to =20= implement type 5 and 6 messages?" FWIW: My short answer: its not. Switching Channels could be accomplished with just type 1 (include) =20 and type 2 (exclude) messages. IMHO: type 5 and 6 messages are used when you are receiving from a =20 large number of sources simultaneously and want to add to or remove from those sources =20 without affecting the others. But again, an "include (S,G)" and and "exclude (S,G)" could accomplish =20 this same thing depending on how the router processed the request. You see, putting a "I want to received from all sources except this =20 one" message into PIM is problematic. It would result in a message that contained a =20 (*,G) join with an (S,G,rp-bit) prune. I'm not saying it can't be done (or shouldn't be done), just that it =20 isn't clear at this point that it is worth doing. One of the reasons for this is that the internet is (I hope) =20 transitioning away from sparse-mode. Bi-dir does not have the capability of forwarding all sources except =20 one. SSM does not have the capability of forwarding all sources on a =20 shared path. My point is not that this can't be done, but rather to question =20 whether or not it should be. If you accept my premise that it should not be, then IGMPv3 type 5 =20 and type 6 messages are not very useful. And type 3 and type 4 messages become redundant. I have to emphasize that this is an opinion on the practicality of =20 implementing all of IGMPv3 and not on whether or not it works. If a -real- application can be defined =20 that would require the additional capability, then, of course, my response would change. I refer you to the history of PIM and the development of dense mode. On Jan 4, 2006, at 10:16 PM, fei wang wrote: > Let=92s suppose an IPTV deployment scenario. > > > > There have two TV station TVs1 and TVs2 which may correspond to two =20= > multicast Sources in PIM. And multiple channels associated with =20 > each TV station which may correspond to multicast Group in PIM. > > > > And normally the user do a channel zapping, which may result in the =20= > type6 BLOCK_OLD_SOURCES( TVs1, G1 ) and type5 ALLOW_NEW_SOURCE=20 > ( TVs2, G2) sending. I am wondering, for one Group when will the =20 > end user device (STB or PC) send such Source-List-Change records? =20 > Since the same multicast Group could NOT be owned by two Sources =20 > (TV station in IPTV). > > > > Since the IGMPV3 RFC define the detail Query and Response behavior =20 > for the Source-List-Change record towards one Group, any scenario =20 > will fulfill the rule? And rather, the IGMPv3 is designed to =20 > maintain the one-multiple (one group vs. multiple sources) =20 > relationship, however for the IPVT, in many cases, it use one =20 > Source (TV station) vs. Multiple Group (channel) model. Any one can =20= > explain the difference from the realistic applications (besides IPTV)? > > > > Regards, > > > > Fei > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim --Apple-Mail-2--384348681 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I think the the question you = were asking was, "How practical is it to implement type 5 and = 6

messages?"=A0=A0

FWIW:=A0 My short answer: = its not.

Switching Channels could be = accomplished with just type 1 (include) and type 2 (exclude) = messages.

IMHO:= type 5 and 6 messages are used when you are receiving from a large = number of sources

simultaneously and want to add to or remove = from those sources without affecting the others.=A0 But

again, = an "include (S,G)" and and "exclude (S,G)" could accomplish this same = thing depending on

how the router processed the = request.

You = see, putting a "I want to received from all sources except this one" = message into

PIM is problematic.=A0 It would result in a = message that contained a (*,G) join with an (S,G,rp-bit) = prune.

I'm not saying it can't be done (or shouldn't be done), = just that it isn't clear at this point=A0

that it is worth = doing.=A0

One = of the reasons for this is that the internet is (I hope) transitioning = away from sparse-mode.

Bi-dir does not have the capability of = forwarding all sources except one.

SSM does not have the = capability of forwarding all sources on a shared path.

My point is not that this = can't be done, but rather to question whether or not it should = be.

If you accept my premise that it should not be, then = IGMPv3 type 5 and type 6 messages

are not very useful.=A0 And = type 3 and type 4 messages become redundant.

I have to emphasize that = this is an opinion on the practicality of implementing all of IGMPv3 and = not

on whether or not it works.=A0 If a -real- application can = be defined that would require the

additional capability, then, = of course, my response would change.

I refer you to the history = of PIM and the development of dense mode.

On Jan = 4, 2006, at 10:16 PM, fei wang wrote:

Let=92s suppose an IPTV = deployment scenario.
=A0
There have two TV station = TVs1 and TVs2 which may correspond to two multicast Sources in PIM. And = multiple channels associated with each TV station which may correspond = to multicast Group in PIM.
=A0
And normally the user do a = channel zapping, which may result in the type6 BLOCK_OLD_SOURCES( TVs1, = G1 ) and type5 ALLOW_NEW_SOURCE( TVs2, G2) sending. I am wondering, for = one Group when will the end user device (STB or PC) send such = Source-List-Change records? Since the same multicast Group could NOT be = owned by two Sources (TV station in IPTV). =
=A0
Since the IGMPV3 RFC define = the detail Query and Response behavior for the Source-List-Change record = towards one Group, any scenario will fulfill the rule? And rather, the = IGMPv3 is designed to maintain the one-multiple (one group vs. multiple = sources) relationship, however for the IPVT, in many cases, it use one = Source (TV station) vs. Multiple Group (channel) model. Any one can = explain the difference from the realistic applications (besides IPTV)? =
=A0
Regards,
=A0
Fei

pim mailing list
pim@ietf.org
https://www1.ietf.org/= mailman/listinfo/pim
=

= --Apple-Mail-2--384348681-- --===============0396502555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============0396502555==-- From pim-bounces@ietf.org Mon Jan 09 15:01:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew3Cl-0004yM-0E; Mon, 09 Jan 2006 15:01:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew3Cj-0004yC-Uq for pim@megatron.ietf.org; Mon, 09 Jan 2006 15:01:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18061 for ; Mon, 9 Jan 2006 15:00:01 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew3JC-0001em-NZ for pim@ietf.org; Mon, 09 Jan 2006 15:08:08 -0500 Received: from jnatalepc (jnatale-pc.avici.com [10.2.20.47]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id k09K10F2003009; Mon, 9 Jan 2006 15:01:00 -0500 From: "Jonathan Natale" To: "Dev" , Subject: RE: [pim] PIM-SM - IP Address of Register messages Date: Mon, 9 Jan 2006 15:01:00 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060109185709.1CF05988711@alpha.sajtx.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.5 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0049543557==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org This is a multi-part message in MIME format. --===============0049543557== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0095_01C6152D.810F8F30" This is a multi-part message in MIME format. ------=_NextPart_000_0095_01C6152D.810F8F30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit IPADDR(IF_B) -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of Dev Sent: Monday, January 09, 2006 2:57 PM To: pim@ietf.org Subject: [pim] PIM-SM - IP Address of Register messages Hello I have a question about the IP address of a register message with multicast payload. Consider this. One router with the interfaces IF_A and IF_B. It receives a multicast stream from a directly connected neighbor on IF_A. The router has been chosen to be the DR on this interface and encapsulates the stream and forwards it onto IF_B, which is in the direction towards the RP. Now my to my question. Which is the correct IP source address of the Register packet. (The external IP header). Is it IPADDR(IF_A) or IPADDR(IF_B)? Or maybe it doesn't matter? Best regards David ------=_NextPart_000_0095_01C6152D.810F8F30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

IPADDR(IF_B)

-----Original Message-----
From: = pim-bounces@ietf.org=20 [mailto:pim-bounces@ietf.org]On Behalf Of Dev
Sent: = Monday,=20 January 09, 2006 2:57 PM
To: pim@ietf.org
Subject: = [pim]=20 PIM-SM - IP Address of Register messages

Hello

I have a question about the IP address of a register message with = multicast=20 payload.

Consider this.
One router with the interfaces IF_A and IF_B. It = receives a multicast stream from a directly connected neighbor on = IF_A. The=20 router has been chosen to be the DR on this interface and encapsulates = the=20 stream and forwards it onto IF_B, which is in the direction towards = the=20 RP.

Now my to my question.
Which is the correct IP source address = of the=20 Register packet. (The external IP header). Is it IPADDR(IF_A) or = IPADDR(IF_B)?=20 Or maybe it doesn't matter?

Best regards
David

------=_NextPart_000_0095_01C6152D.810F8F30-- --===============0049543557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============0049543557==-- From pim-bounces@ietf.org Tue Jan 10 12:01:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMsU-0000S8-Eg; Tue, 10 Jan 2006 12:01:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMsS-0000S0-JG for pim@megatron.ietf.org; Tue, 10 Jan 2006 12:01:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21233 for ; Tue, 10 Jan 2006 12:00:21 -0500 (EST) Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMz7-0000iY-FS for pim@ietf.org; Tue, 10 Jan 2006 12:08:38 -0500 Received: from hadron ([130.59.4.84] helo=hadron.switch.ch) by central.switch.ch with esmtp (Exim 3.20 #1) id 1EwMrv-0003z7-00; Tue, 10 Jan 2006 18:01:11 +0100 Received: from hadron.switch.ch.switch.ch (localhost [IPv6:::1]) by hadron.switch.ch (8.13.4+Sun/8.13.4) with ESMTP id k0AH18Dx013015; Tue, 10 Jan 2006 18:01:08 +0100 (CET) From: Alexander Gall MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17347.59476.667952.163220@hadron.switch.ch> Date: Tue, 10 Jan 2006 18:01:08 +0100 To: "Jonathan Natale" Subject: RE: [pim] PIM-SM - IP Address of Register messages In-Reply-To: References: <20060109185709.1CF05988711@alpha.sajtx.net> X-Mailer: VM 7.18 under Emacs 21.3.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org On Mon, 9 Jan 2006 15:01:00 -0500, "Jonathan Natale" said: > IPADDR(IF_B) Why? I think it doesn't matter. Cisco's IPv6 implementaion lets me chose it with ipv6 pim register-source This can be useful for exmple if - the unicast address of the outgoing interface towards the RP is not reachable by the RP (and hence register-stop messages couldn't be received by the DR). - the RP uses a fine-grained ACL to restrict the sources of register messages (e.g. the loopback addresses of the DRs) -- Alex > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of Dev > Sent: Monday, January 09, 2006 2:57 PM > To: pim@ietf.org > Subject: [pim] PIM-SM - IP Address of Register messages > Hello > I have a question about the IP address of a register message with > multicast payload. > Consider this. > One router with the interfaces IF_A and IF_B. It receives a multicast > stream from a directly connected neighbor on IF_A. The router has been > chosen to be the DR on this interface and encapsulates the stream and > forwards it onto IF_B, which is in the direction towards the RP. > Now my to my question. > Which is the correct IP source address of the Register packet. (The > external IP header). Is it IPADDR(IF_A) or IPADDR(IF_B)? Or maybe it doesn't > matter? > Best regards > David _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jan 10 12:32:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwNMQ-00032C-Ji; Tue, 10 Jan 2006 12:32:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwNMP-000325-AF for pim@megatron.ietf.org; Tue, 10 Jan 2006 12:32:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23438 for ; Tue, 10 Jan 2006 12:31:21 -0500 (EST) Received: from [208.246.215.5] (helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwNT5-0001hh-Vl for pim@ietf.org; Tue, 10 Jan 2006 12:39:39 -0500 Received: from jnatalepc (jnatale-pc.avici.com [10.2.20.47]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id k0AHWPF2015621; Tue, 10 Jan 2006 12:32:25 -0500 From: "Jonathan Natale" To: "Alexander Gall" Subject: RE: [pim] PIM-SM - IP Address of Register messages Date: Tue, 10 Jan 2006 12:32:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <17347.59476.667952.163220@hadron.switch.ch> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Hello. because the outgoing interface IS the src. Sure you can change it, but that was not the question; defaulting to loopback0 MIGHT make sense, but why default to the address of the interface used to reach the mcast source? > -----Original Message----- > From: Alexander Gall [mailto:gall@switch.ch] > Sent: Tuesday, January 10, 2006 12:01 PM > To: Jonathan Natale > Cc: Dev; pim@ietf.org > Subject: RE: [pim] PIM-SM - IP Address of Register messages > > > On Mon, 9 Jan 2006 15:01:00 -0500, "Jonathan Natale" > said: > > > IPADDR(IF_B) > > Why? I think it doesn't matter. Cisco's IPv6 implementaion lets me > chose it with > > ipv6 pim register-source > > This can be useful for exmple if > > - the unicast address of the outgoing interface towards the RP is not > reachable by the RP (and hence register-stop messages couldn't be > received by the DR). > > - the RP uses a fine-grained ACL to restrict the sources of register > messages (e.g. the loopback addresses of the DRs) > > -- > Alex > > > -----Original Message----- > > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On > Behalf Of Dev > > Sent: Monday, January 09, 2006 2:57 PM > > To: pim@ietf.org > > Subject: [pim] PIM-SM - IP Address of Register messages > > > > Hello > > > I have a question about the IP address of a register message with > > multicast payload. > > > Consider this. > > One router with the interfaces IF_A and IF_B. It receives a multicast > > stream from a directly connected neighbor on IF_A. The router has been > > chosen to be the DR on this interface and encapsulates the stream and > > forwards it onto IF_B, which is in the direction towards the RP. > > > Now my to my question. > > Which is the correct IP source address of the Register packet. (The > > external IP header). Is it IPADDR(IF_A) or IPADDR(IF_B)? Or > maybe it doesn't > > matter? > > > Best regards > > David _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jan 10 12:42:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwNW9-0006D7-Sg; Tue, 10 Jan 2006 12:42:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwNW7-0006Cl-Ej for pim@megatron.ietf.org; Tue, 10 Jan 2006 12:42:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24133 for ; Tue, 10 Jan 2006 12:41:23 -0500 (EST) Received: from [208.246.215.5] (helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwNcr-00021t-To for pim@ietf.org; Tue, 10 Jan 2006 12:49:42 -0500 Received: from jnatalepc (jnatale-pc.avici.com [10.2.20.47]) by mailhost.avici.com (8.12.8/8.12.8) with SMTP id k0AHgQF2017895; Tue, 10 Jan 2006 12:42:26 -0500 From: "Jonathan Natale" To: "Alexander Gall" Subject: RE: [pim] PIM-SM - IP Address of Register messages Date: Tue, 10 Jan 2006 12:42:26 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <17347.59476.667952.163220@hadron.switch.ch> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Avici-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org it may matter if any of the routers along the path of the register do a uRPF (which may be done for security purposes). > -----Original Message----- > From: Alexander Gall [mailto:gall@switch.ch] > Sent: Tuesday, January 10, 2006 12:01 PM > To: Jonathan Natale > Cc: Dev; pim@ietf.org > Subject: RE: [pim] PIM-SM - IP Address of Register messages > > > On Mon, 9 Jan 2006 15:01:00 -0500, "Jonathan Natale" > said: > > > IPADDR(IF_B) > > Why? I think it doesn't matter. Cisco's IPv6 implementaion lets me > chose it with > > ipv6 pim register-source > > This can be useful for exmple if > > - the unicast address of the outgoing interface towards the RP is not > reachable by the RP (and hence register-stop messages couldn't be > received by the DR). > > - the RP uses a fine-grained ACL to restrict the sources of register > messages (e.g. the loopback addresses of the DRs) > > -- > Alex > > > -----Original Message----- > > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On > Behalf Of Dev > > Sent: Monday, January 09, 2006 2:57 PM > > To: pim@ietf.org > > Subject: [pim] PIM-SM - IP Address of Register messages > > > > Hello > > > I have a question about the IP address of a register message with > > multicast payload. > > > Consider this. > > One router with the interfaces IF_A and IF_B. It receives a multicast > > stream from a directly connected neighbor on IF_A. The router has been > > chosen to be the DR on this interface and encapsulates the stream and > > forwards it onto IF_B, which is in the direction towards the RP. > > > Now my to my question. > > Which is the correct IP source address of the Register packet. (The > > external IP header). Is it IPADDR(IF_A) or IPADDR(IF_B)? Or > maybe it doesn't > > matter? > > > Best regards > > David _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jan 10 13:30:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOGY-0003Ri-BH; Tue, 10 Jan 2006 13:30:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOGX-0003RM-35 for pim@megatron.ietf.org; Tue, 10 Jan 2006 13:30:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27507 for ; Tue, 10 Jan 2006 13:29:20 -0500 (EST) Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwONG-0003Vn-B2 for pim@ietf.org; Tue, 10 Jan 2006 13:37:39 -0500 Received: from hadron ([130.59.4.84] helo=hadron.switch.ch) by central.switch.ch with esmtp (Exim 3.20 #1) id 1EwOFw-0001jZ-00; Tue, 10 Jan 2006 19:30:04 +0100 Received: from hadron.switch.ch.switch.ch (localhost [IPv6:::1]) by hadron.switch.ch (8.13.4+Sun/8.13.4) with ESMTP id k0AIU4x1028731; Tue, 10 Jan 2006 19:30:04 +0100 (CET) From: Alexander Gall MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17347.64812.193702.813025@hadron.switch.ch> Date: Tue, 10 Jan 2006 19:30:04 +0100 To: "Jonathan Natale" Subject: RE: [pim] PIM-SM - IP Address of Register messages In-Reply-To: References: <17347.59476.667952.163220@hadron.switch.ch> X-Mailer: VM 7.18 under Emacs 21.3.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org On Tue, 10 Jan 2006 12:32:25 -0500, "Jonathan Natale" said: > Hello. because the outgoing interface IS the src. Sure you can change it, > but that was not the question; defaulting to loopback0 MIGHT make sense, but > why default to the address of the interface used to reach the mcast source? You seem to have a different interpretation of what the OP meant by "correct". I read the question to ask whether PIM-SM makes any statement about which source address to chose. I think it doesn't and the choice is a matter of local policy. Your first reply suggested something different to me, hence my statement. -- Alex _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Jan 11 14:23:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwlZO-0001UU-Ja; Wed, 11 Jan 2006 14:23:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwlZN-0001U4-Al for pim@megatron.ietf.org; Wed, 11 Jan 2006 14:23:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05042 for ; Wed, 11 Jan 2006 14:22:20 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwlgK-0004j2-9f for pim@ietf.org; Wed, 11 Jan 2006 14:30:53 -0500 Received: by zproxy.gmail.com with SMTP id 9so226393nzo for ; Wed, 11 Jan 2006 11:23:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jDKdr8JXQxRzUglQazFn035kMgqe2BFFOh+9o8cf+k5uUfMjwjCEekcwgADGZQ4tkXXHIp20QR/S/g+eUrde2eoI5NtCxOAV5wb8bjFElubMhRmcsuaOjodaqiIcHu0gi6Rym3hkxNveN7m1kY/zP7LuGVlm3aEtlGmPlNgGfwc= Received: by 10.36.247.62 with SMTP id u62mr1111651nzh; Wed, 11 Jan 2006 11:23:38 -0800 (PST) Received: by 10.36.46.2 with HTTP; Wed, 11 Jan 2006 11:23:38 -0800 (PST) Message-ID: Date: Wed, 11 Jan 2006 14:23:38 -0500 From: Marshall Eubanks To: Mike McBride Subject: Re: [pim] WG Last Call - draft-ietf-pim-join-attributes-00 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org On 1/3/06, Mike McBride wrote: > Today begins a 2 week working group last call for the pim-join-attributes > draft. January 17th, 2006 will be the final day of the last call. Please > review this document and send any comments to the list. > > http://www.ietf.org/internet-drafts/draft-ietf-pim-join-attributes-00.txt > > thanks, > mike > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > Hello; I read this document and found it to be in general well written and=20 suitable for publishing. I have one nit, one small question, and one major question. Major Question : This document seems to be written entirely from the standpoint of allowing for attributes for (S,G) joins only. Since my understanding is that these capabilities are being added for things like L3VPN, which supports ASM and BiDir, why shouldn't (*,G) attributes be supported ? If, in the opinion of the author's, (*,G) attributes ARE supported already, then I don't think that this is clear. I would urge that (*,G) attributes be supported, and that text be added to make this point clear. Minor Question / point In Section 2.2 It may be desired to have routers that understand the generic attribute format, forward the attributes regardless if they understand the TLV's encoded in the attribute not. For this the first bit in the Type field is reserved. If this bit is set then the TLV is forwarded upstream in case the router does not understand that type. Is this forwarding with the bit set a MUST ? Then specify it so, and add the following boiler plate : In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 and indicate requirement levels for compliant PIM-SM implementations. AND, what if the bit is not set ? Is that a "MUST NOT" forward, or is that left to the implementor ? I would suggest that this be made explicit. Nit : Section 2.3 (Even a router which is not the upstream neighbor must be able parse the packet in order to do Join suppression or overriding.) s/able parse/able to parse/ Regards Marshall Eubanks _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Jan 11 15:18:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmQN-0002Lo-Od; Wed, 11 Jan 2006 15:18:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmQM-0002Kz-CX for pim@megatron.ietf.org; Wed, 11 Jan 2006 15:18:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09877 for ; Wed, 11 Jan 2006 15:17:05 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwmXJ-0006G9-It for pim@ietf.org; Wed, 11 Jan 2006 15:25:39 -0500 Received: from tyholt-ng.uninett.no (tyholt-ng.uninett.no [IPv6:2001:700:1::eecb]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id k0BKIJe9026835; Wed, 11 Jan 2006 21:18:19 +0100 Date: Wed, 11 Jan 2006 21:18:19 +0100 From: Stig Venaas To: Bharat Joshi Subject: Re: [pim] Some questions on join-attributed draft Message-ID: <20060111201819.GA3697@tyholt.uninett.no> References: <1136432893.13599.7.camel@magadha> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1136432893.13599.7.camel@magadha> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org On Thu, Jan 05, 2006 at 09:18:13AM +0530, Bharat Joshi wrote: > > Hi, > > I have couple of questions: > > * Can we rephrase the following statement in section 2.2: > > "forward the attributes regardless if they understand the TLV's encoded > in the attribute not." to forward the attributes regardless of whether > they understand the TLV's encoded in the attribute or not. > > * In section 2.2, the document says: > "If this bit is set then the TLV is forwarded upstream in case the > router does not understand that type." This seems to be conflicting with > what is mentioned just above this statement. In the first statement, There is a difference between not understanding this option, and not understanding a specific attribute. > document mention to have a way to forward TLV to upstream regardless of > whether a router understands it and in this statement we say that router > will forward it when router does not understand it. > > * In section 2.6, the document says: > "Attributes not processed are passed upstream unchanged.". Is this done > based on the bit defined in section 2.2 or regardless of that bit, these > TLVs are forwarded to upstream? I would guess so, but it's not clear. So I would like to see this clarified. > * In section 3.1, there is no length field in source encoding type so > how does a router will know that there are any TLVs after the source > address? I assume you don't use this source encoding if you have no TLVs, but this should also be made clear. > * There is no section about the "Security Consideration" in the > document. Right. For it to be accepted, there must be security considerations, and also a longer abstract. Stig > > Thanks & 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*** > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Jan 11 15:25:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmXN-000488-3y; Wed, 11 Jan 2006 15:25:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmXL-000483-PD for pim@megatron.ietf.org; Wed, 11 Jan 2006 15:25:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10212 for ; Wed, 11 Jan 2006 15:24:18 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwmeJ-0006RH-RU for pim@ietf.org; Wed, 11 Jan 2006 15:32:52 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id k0BKPXe9028339; Wed, 11 Jan 2006 21:25:33 +0100 Message-ID: <43C569BB.4040803@uninett.no> Date: Wed, 11 Jan 2006 21:25:31 +0100 From: Stig Venaas User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marshall Eubanks Subject: Re: [pim] WG Last Call - draft-ietf-pim-join-attributes-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: Mike McBride , pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Marshall Eubanks wrote: >On 1/3/06, Mike McBride wrote: > > >>Today begins a 2 week working group last call for the pim-join-attributes >>draft. January 17th, 2006 will be the final day of the last call. Please >>review this document and send any comments to the list. >> >>http://www.ietf.org/internet-drafts/draft-ietf-pim-join-attributes-00.txt >> >>thanks, >>mike >> >>_______________________________________________ >>pim mailing list >>pim@ietf.org >>https://www1.ietf.org/mailman/listinfo/pim >> >> >> > > >Hello; > >I read this document and found it to be in general well written and >suitable for >publishing. I have one nit, one small question, and one major question. > >Major Question : This document seems to be written entirely from the >standpoint of >allowing for attributes for (S,G) joins only. > >Since my understanding is that these capabilities are being added for >things like L3VPN, which supports ASM and BiDir, why shouldn't (*,G) >attributes be supported ? > > > I think it is. In that case the source address is the RP address. But it might be good to clarify this. I definitely want it to be there for (*,G), so bad if some implementors read it differently. >If, in the opinion of the author's, (*,G) attributes ARE supported >already, then I don't think that this is clear. > >I would urge that (*,G) attributes be supported, and that text be >added to make this point clear. > >Minor Question / point > >In Section 2.2 > > It may be desired to have routers that understand the generic > attribute format, forward the attributes regardless if they > understand the TLV's encoded in the attribute not. For this the > first bit in the Type field is reserved. If this bit is set then the > TLV is forwarded upstream in case the router does not understand that > type. > >Is this forwarding with the bit set a MUST ? Then specify it so, and >add the following boiler plate : > >In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", >"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >"OPTIONAL" are to be interpreted as described in RFC 2119 and indicate >requirement levels for compliant PIM-SM implementations. > >AND, what if the bit is not set ? Is that a "MUST NOT" forward, or is >that left to the implementor ? I would suggest that this be made >explicit. > > > Agree Stig >Nit : Section 2.3 > >(Even a router which > is not the upstream neighbor must be able parse the packet in order > to do Join suppression or overriding.) > >s/able parse/able to parse/ > >Regards >Marshall Eubanks > >_______________________________________________ >pim mailing list >pim@ietf.org >https://www1.ietf.org/mailman/listinfo/pim > > _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jan 13 02:01:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExIwS-0001h4-08; Fri, 13 Jan 2006 02:01:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExIwP-0001d6-Iv for pim@megatron.ietf.org; Fri, 13 Jan 2006 02:01:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07210 for ; Fri, 13 Jan 2006 02:00:19 -0500 (EST) Received: from h-83-140-32-156.ip.cust.port80.se ([83.140.32.156] helo=alpha.sajtx.net ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExJ3V-0006hV-Hw for pim@ietf.org; Fri, 13 Jan 2006 02:09:02 -0500 Received: from localhost (sajtx.net [127.0.0.1]) by alpha.sajtx.net (Postfix) with ESMTP id 46962988727 for ; Fri, 13 Jan 2006 08:01:05 +0100 (CET) Received: from alpha.sajtx.net ([127.0.0.1]) by localhost (alpha [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28952-08 for ; Fri, 13 Jan 2006 08:01:04 +0100 (CET) Received: from UebiMiau (sajtx.net [127.0.0.1]) by alpha.sajtx.net (Postfix) with SMTP id C4AC99886EB for ; Fri, 13 Jan 2006 08:01:04 +0100 (CET) Received: from client 85.11.194.1 for UebiMiau2.7 (webmail client); Fri, 13 Jan 2006 8:01:04 -0000 Date: Fri, 13 Jan 2006 8:01:04 -0000 From: "David Henriksson" To: pim@ietf.org X-Priority: 3 X-Mailer: UebiMiau 2.7.2 X-Original-IP: 85.11.194.1 X-MSMail-Priority: Medium Importance: Medium Content-Type: text/plain; charset="iso-8859-1"; MIME-Version: 1.0 Message-Id: <20060113070104.C4AC99886EB@alpha.sajtx.net> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at sajtx.net Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Subject: [pim] status of PIM-SM draft 11 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Henriksson List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Hello, This might be a stupid question but, what is the status of the PIM-SM v11 draft? It says that it expired in April 2005. Will it repleace RFC 2362? _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jan 13 02:52:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExJjo-0000aF-TF; Fri, 13 Jan 2006 02:52:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExJjn-0000Yl-6o for pim@megatron.ietf.org; Fri, 13 Jan 2006 02:52:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10394 for ; Fri, 13 Jan 2006 02:51:21 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExJr3-00089p-B3 for pim@ietf.org; Fri, 13 Jan 2006 03:00:14 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 12 Jan 2006 23:52:32 -0800 X-IronPort-AV: i="3.99,362,1131350400"; d="scan'208"; a="391313210:sNHT30543876" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0D7qWQi003826; Thu, 12 Jan 2006 23:52:32 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 23:52:31 -0800 Received: from irp-view6.cisco.com ([171.70.65.143]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 23:52:31 -0800 Date: Thu, 12 Jan 2006 23:52:31 -0800 (PST) From: Mike McBride To: David Henriksson Subject: Re: [pim] status of PIM-SM draft 11 In-Reply-To: <20060113070104.C4AC99886EB@alpha.sajtx.net> Message-ID: References: <20060113070104.C4AC99886EB@alpha.sajtx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 13 Jan 2006 07:52:31.0923 (UTC) FILETIME=[4EEE6030:01C61816] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org > This might be a stupid question but, > what is the status of the PIM-SM v11 draft? Good question. Fenner has a few remaining modifications then its done. Perhaps send him some flowers as encouragement. > It says that it expired in April 2005. > Will it repleace RFC 2362? That date listed on the draft is wrong. Its alive and in IESG hands and yes, we'll eventually have a new RFC. We are expecting completion by Dallas. mike > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jan 17 16:55:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyyne-00047q-5B; Tue, 17 Jan 2006 16:55:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyync-00047l-Mx for pim@megatron.ietf.org; Tue, 17 Jan 2006 16:55:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28237 for ; Tue, 17 Jan 2006 16:54:06 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyyvo-0002MU-IO for pim@ietf.org; Tue, 17 Jan 2006 17:04:01 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 17 Jan 2006 13:55:22 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0HLtMQi007308 for ; Tue, 17 Jan 2006 13:55:22 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 13:55:22 -0800 Received: from irp-view6.cisco.com ([171.70.65.143]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Jan 2006 13:55:21 -0800 Date: Tue, 17 Jan 2006 13:55:21 -0800 (PST) From: Mike McBride To: pim@ietf.org Subject: Re: [pim] WG Last Call - draft-ietf-pim-join-attributes-00 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 17 Jan 2006 21:55:22.0031 (UTC) FILETIME=[B6B77BF0:01C61BB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Thanks for the comments from Bharat, Stig and Marshall. The authors of this draft will be directed to clarify the sections in question and add a security section to an -01 version. Please send any remaining comments, on this draft, as the LC ends today. thanks, mike On Tue, 3 Jan 2006, Mike McBride wrote: > Today begins a 2 week working group last call for the pim-join-attributes > draft. January 17th, 2006 will be the final day of the last call. Please > review this document and send any comments to the list. > > http://www.ietf.org/internet-drafts/draft-ietf-pim-join-attributes-00.txt > > thanks, > mike > > _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Jan 18 02:23:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez7f8-0002kk-Gr; Wed, 18 Jan 2006 02:23:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez7f6-0002jF-0k for pim@megatron.ietf.org; Wed, 18 Jan 2006 02:23:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12670 for ; Wed, 18 Jan 2006 02:21:54 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez7nJ-0005aC-66 for pim@ietf.org; Wed, 18 Jan 2006 02:31:50 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0I7MiHe003182; Wed, 18 Jan 2006 09:22:55 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0I6boLS002238; Wed, 18 Jan 2006 08:37:50 +0200 Date: Wed, 18 Jan 2006 08:37:50 +0200 (EET) From: Pekka Savola To: Mike McBride Subject: Re: [pim] WG Last Call - draft-ietf-pim-join-attributes-00 In-Reply-To: Message-ID: References:

X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: Mike McBride , pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Hello; On 1/18/06, Pekka Savola wrote: > Actually, as a more generic point, I'm not sure whether IANA > registry(ies) should be created (here or in pim-sm-v2-new), as > apparently PIM specs are going to be extended by other specs. IANA Do you mean this spec, or by L3VPN add ons or ... ? In any case, I would support creation of a IANA PIM Resgistry. Who knows what the future will need ? Regards Marshall > already controls the Hello Options, but it seems we should create a > registry for some other numbers in the PIM spec as well? > > On Tue, 17 Jan 2006, Mike McBride wrote: > > Thanks for the comments from Bharat, Stig and Marshall. The authors of = this > > draft will be directed to clarify the sections in question and add a se= curity > > section to an -01 version. Please send any remaining comments, on this = draft, > > as the LC ends today. > > While you're at it, check the other nits as well: > > http://tools.ietf.org/wg/pim/draft-ietf-pim-join-attributes/draft-ietf-pi= m-join-attributes-00.nits.txt > > By a quick glance, I found the document a bit lacking in > descriptiveness (e.g., what does Hello option's "OptionType =3D XX" > mean). I'd also have swapped the order of sections 2 and 3 but it's > OK as is. > > Especially, add IANA considerations section as well for the new TLV > values. > > In what units is the Length field in section 3.1? Does this include > only the length of the 'Value' or flags, type and length fields as > well? > > I think you should write the PIM Join packet format instead as > something like: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |PIM Ver| Type | Reserved | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Address (Encoded-Source format) > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..... > |F|S| Type | Length | Value > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..... > |F|S| Type | Length | Value > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..... > > This is closer to what pim-v2-sm-new describes, doesn't overlap the > format of the encoded-source format, makes it clearer that Source > Address field can be longer than 4 bytes, etc. > > It's a bit odd that there's no clear "length" anywhere here, but I > guess you have to use what you have.. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Jan 18 03:59:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez9AC-0007Wi-Eq; Wed, 18 Jan 2006 03:59:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez9AA-0007Vj-Ub for pim@megatron.ietf.org; Wed, 18 Jan 2006 03:59:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19665 for ; Wed, 18 Jan 2006 03:58:04 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez9IR-0000LR-WD for pim@ietf.org; Wed, 18 Jan 2006 04:08:05 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0I8x8Ha005650; Wed, 18 Jan 2006 10:59:08 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0I8x8uq005647; Wed, 18 Jan 2006 10:59:08 +0200 Date: Wed, 18 Jan 2006 10:59:08 +0200 (EET) From: Pekka Savola To: Marshall Eubanks Subject: Re: [pim] WG Last Call - draft-ietf-pim-join-attributes-00 In-Reply-To: Message-ID: References:

MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Mike McBride , pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org On Wed, 18 Jan 2006, Marshall Eubanks wrote: > On 1/18/06, Pekka Savola wrote: >> Actually, as a more generic point, I'm not sure whether IANA >> registry(ies) should be created (here or in pim-sm-v2-new), as >> apparently PIM specs are going to be extended by other specs. IANA > > Do you mean this spec, or by L3VPN add ons or ... ? I was referring the need shown by this spec. There are probably other, new ones coming. There currently is an IANA registry for Hello options and address families, but that's it. Btw, later on I realized I was a bit confused in my comment below, because the format diagram was meant to show just the new Encoded-Source format, not the whole message. In any case, the the comment about source address not necessarily being 4 bytes is valid and should be reflected in the diagram: >> I think you should write the PIM Join packet format instead as >> something like: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |PIM Ver| Type | Reserved | Checksum | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Source Address (Encoded-Source format) >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..... >> |F|S| Type | Length | Value >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..... >> |F|S| Type | Length | Value >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..... >> >> This is closer to what pim-v2-sm-new describes, doesn't overlap the >> format of the encoded-source format, makes it clearer that Source >> Address field can be longer than 4 bytes, etc. >> >> It's a bit odd that there's no clear "length" anywhere here, but I >> guess you have to use what you have.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jan 24 15:51:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1V83-0004Ms-2D; Tue, 24 Jan 2006 15:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1V79-0003xV-T0; Tue, 24 Jan 2006 15:50:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17954; Tue, 24 Jan 2006 15:48:35 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1VGi-0002mW-2N; Tue, 24 Jan 2006 16:00:01 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F1V74-0002ce-Nw; Tue, 24 Jan 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 24 Jan 2006 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-mib-v2-05.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Protocol Independent Multicast MIB Author(s) : J. Lingard, et al. Filename : draft-ietf-pim-mib-v2-05.txt Pages : 85 Date : 2006-1-24 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocols (PIM-SM and BIDIR- PIM). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC 2934. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-mib-v2-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-mib-v2-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-mib-v2-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-24151916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-mib-v2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-mib-v2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-24151916.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From pim-bounces@ietf.org Wed Jan 25 04:38:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1h6K-0001ch-5c; Wed, 25 Jan 2006 04:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1h6I-0001aK-BL for pim@megatron.ietf.org; Wed, 25 Jan 2006 04:38:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25276 for ; Wed, 25 Jan 2006 04:36:30 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1hG0-00013u-3P for pim@ietf.org; Wed, 25 Jan 2006 04:48:05 -0500 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jan 2006 09:37:46 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [pim] I-D ACTION:draft-ietf-pim-mib-v2-05.txt Date: Wed, 25 Jan 2006 09:37:47 -0000 Message-ID: <465A601C1F3AB5489335DFCECF20951B09F9FE@enfimail1.datcon.co.uk> Thread-Topic: [pim] I-D ACTION:draft-ietf-pim-mib-v2-05.txt Thread-Index: AcYhKq3zzqovG4hVStSdkZsvcCzyyQAZwktQ From: "David McWalter" To: X-OriginalArrivalTime: 25 Jan 2006 09:37:46.0979 (UTC) FILETIME=[FFF47330:01C62192] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Folks, I just submitted this new version of PIM-MIB. This includes all feedback received to date. There are no outstanding = issues. If anyone has further comments or suggestions, please let me know by Fri = 3 February. Then I'll talk to the chairs about when we should run the = WG Last Call. All the best, David McW. _Main changes in -v2-05_ - Added PIM-DM objects and text supplied by Jonathan Nicolas. - Added equivalent counters for all traps. - Added fields to enable/disable traps. Only pimNeighborLoss is = enabled by default. - Added mandatory rate limiting for pimInvalidRegister and = pimInvalidJoinPrune. - Added section 5 security notes on DoS risk of pimInvalidRegister, = describing how DoS resilience is achieved. - Did *not* add any per-(*,G,I) or per-(S,G,I) assert information. = Occupancy there would be too costly. - Instead added global objects to allow administrators to see whether = asserts are happening via the MIB. - Plus some more minor points, as per my mail of Fri 16 December. -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: 24 January 2006 20:50 To: i-d-announce@ietf.org Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-mib-v2-05.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Protocol Independent Multicast Working = Group of the IETF. Title : Protocol Independent Multicast MIB Author(s) : J. Lingard, et al. Filename : draft-ietf-pim-mib-v2-05.txt Pages : 85 Date : 2006-1-24 =09 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocols (PIM-SM and BIDIR- PIM). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC 2934. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-mib-v2-05.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-mib-v2-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-mib-v2-05.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jan 30 08:46:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3ZMW-0003Rb-Mf; Mon, 30 Jan 2006 08:46:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3ZMV-0003M8-EH for pim@megatron.ietf.org; Mon, 30 Jan 2006 08:46:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23720 for ; Mon, 30 Jan 2006 08:44:48 -0500 (EST) Received: from webmail-outgoing.us4.outblaze.com ([205.158.62.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3ZX4-00046w-9M for pim@ietf.org; Mon, 30 Jan 2006 08:57:32 -0500 Received: from unknown (unknown [192.168.9.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id 766D41800315 for ; Mon, 30 Jan 2006 13:46:03 +0000 (GMT) X-OB-Received: from unknown (205.158.62.55) by wfilter.us4.outblaze.com; 30 Jan 2006 13:46:03 -0000 Received: by ws1-3.us4.outblaze.com (Postfix, from userid 1001) id 4AF84101D9; Mon, 30 Jan 2006 13:46:02 +0000 (GMT) MIME-Version: 1.0 From: "Arut Selvan" To: pim@ietf.org Date: Mon, 30 Jan 2006 08:46:02 -0500 Received: from [203.126.136.220] by ws1-3.us4.outblaze.com with http for arut@techie.com; Mon, 30 Jan 2006 08:46:02 -0500 X-Originating-Ip: 203.126.136.220 X-Originating-Server: ws1-3.us4.outblaze.com Message-Id: <20060130134602.4AF84101D9@ws1-3.us4.outblaze.com> X-Spam-Score: 0.7 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [pim] Multicast using MBGP X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: ,