From pim-bounces@ietf.org Wed Feb 01 07:04: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 1F4Gii-0005IH-L8; Wed, 01 Feb 2006 07:04:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Gig-0005Ho-Ts for pim@megatron.ietf.org; Wed, 01 Feb 2006 07:04: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 HAA09072 for ; Wed, 1 Feb 2006 07:02:42 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Gtp-0001xU-Nz for pim@ietf.org; Wed, 01 Feb 2006 07:15:51 -0500 Received: from nikhillaptop (nikhil.erg.abdn.ac.uk [139.133.204.171]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k11C42rr005603 for ; Wed, 1 Feb 2006 12:04:02 GMT Message-Id: <200602011204.k11C42rr005603@erg.abdn.ac.uk> From: "Nikhil Ninan" To: Date: Wed, 1 Feb 2006 12:03:57 -0000 MIME-Version: 1.0 X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Importance: High Thread-Index: AcYnJ5RIqwi90/WQROKNQYaitqYEYg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: nikhil@erg.abdn.ac.uk X-Spam-Score: 1.1 (+) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [pim] PIM Hello Messages 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="===============1788471615==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org This is a multi-part message in MIME format. --===============1788471615== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01C62727.97C20300" This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C62727.97C20300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I have a query on PIM Hello Messages: If a PIM router does not receive a Hello Message from one of its neighbors within the "hello_period" will it drop the router's address from its list of neighbors or will it wait for the router to miss a few more "hello_period" 's before it completely removes the router from the list. Any feedback on this would be very useful. Cheers Nikhil ------=_NextPart_000_005F_01C62727.97C20300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

= ; I have a query on PIM Hello = Messages:

If a PIM router does not receive a Hello = Message from one of its neighbors within the “hello_period” will it drop = the router’s address from its list of neighbors or will it wait for = the router to miss a few more “hello_period” ‘s before it completely removes the router from the = list.

Any feedback on this would be very = useful.

Cheers

Nikhil

------=_NextPart_000_005F_01C62727.97C20300-- --===============1788471615== 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 --===============1788471615==-- From pim-bounces@ietf.org Wed Feb 01 07:37:26 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 1F4HEk-0004ey-7l; Wed, 01 Feb 2006 07:37:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4HEf-0004cx-Tx for pim@megatron.ietf.org; Wed, 01 Feb 2006 07:37:23 -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 HAA14577 for ; Wed, 1 Feb 2006 07:35:45 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4HPp-000377-W2 for pim@ietf.org; Wed, 01 Feb 2006 07:48:54 -0500 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 12:37:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [pim] PIM Hello Messages Date: Wed, 1 Feb 2006 12:37:02 -0000 Message-ID: <986E07666EAE1C459DC81492A7FA4CEA0F19B5@enfimail1.datcon.co.uk> Thread-Topic: [pim] PIM Hello Messages Thread-Index: AcYnJ5RIqwi90/WQROKNQYaitqYEYgAA3AAw From: "David McWalter" To: "Nikhil Ninan" X-OriginalArrivalTime: 01 Feb 2006 12:37:02.0840 (UTC) FILETIME=[33D6D780:01C6272C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c 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="===============0513188435==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org This is a multi-part message in MIME format. --===============0513188435== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6272C.33BB664B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6272C.33BB664B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nikhil. =20 A PIM router waits longer than the hello_period before removing its = adjacency with a neighbor. - Periodic Hellos are sent every hello_period seconds (30s by default). - Adjacencies are removed when the neighbor liveness timer expires = (105s by default). =20 See sections 4.3.1, 4.3.2 and 4.11 of the PIM spec for details. http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-11.txt =20 Hope that's helpful. DMcW. =20 -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of = Nikhil Ninan Sent: 01 February 2006 12:04 To: pim@ietf.org Subject: [pim] PIM Hello Messages Importance: High Hello, I have a query on PIM Hello Messages: If a PIM router does not receive a Hello Message from one of its = neighbors within the "hello_period" will it drop the router's address = from its list of neighbors or will it wait for the router to miss a few = more "hello_period" 's before it completely removes the router from the = list. =20 Any feedback on this would be very useful. Cheers Nikhil ------_=_NextPart_001_01C6272C.33BB664B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi=20 Nikhil.

A PIM=20 router waits longer than the hello_period before removing its adjacency = with a=20 neighbor.

- Periodic Hellos are sent every hello_period seconds = (30s by=20 default).

- Adjacencies are removed when the neighbor liveness = timer=20 expires (105s by default).

See=20 sections 4.3.1, 4.3.2 and 4.11 of the PIM spec for=20 details.

http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-11.txt

Hope=20 that's helpful.

DMcW.

-----Original Message-----
From: pim-bounces@ietf.org = [mailto:pim-bounces@ietf.org]On Behalf Of Nikhil = Ninan
Sent: 01=20 February 2006 12:04
To: pim@ietf.org
Subject: [pim] = PIM=20 Hello Messages
Importance: High

Hello,

=20 I have a query on PIM Hello Messages:

If a PIM router does not = receive a=20 Hello Message from one of its neighbors within the = “hello_period” will it drop=20 the router’s address from its list of neighbors or will it wait = for the router=20 to miss a few more “hello_period” ‘s before it = completely removes the router=20 from the list.

Any feedback on this would = be very=20 useful.

Cheers

Nikhil

------_=_NextPart_001_01C6272C.33BB664B-- --===============0513188435== 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 --===============0513188435==-- From pim-bounces@ietf.org Wed Feb 01 08:35: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 1F4I9A-0004ky-3X; Wed, 01 Feb 2006 08:35:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4I97-0004jq-G0 for pim@megatron.ietf.org; Wed, 01 Feb 2006 08:35: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 IAA27094 for ; Wed, 1 Feb 2006 08:34:04 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4IKH-0005j2-Sc for pim@ietf.org; Wed, 01 Feb 2006 08:47:14 -0500 Received: from nikhillaptop (nikhil.erg.abdn.ac.uk [139.133.204.171]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k11DZQbZ012041 for ; Wed, 1 Feb 2006 13:35:26 GMT Message-Id: <200602011335.k11DZQbZ012041@erg.abdn.ac.uk> From: "Nikhil Ninan" To: Date: Wed, 1 Feb 2006 13:35:19 -0000 MIME-Version: 1.0 X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Importance: High Thread-Index: AcYnNFddvvt/qJVoTceb5usBAsbvcg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: nikhil@erg.abdn.ac.uk X-Spam-Score: 1.2 (+) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Subject: [pim] PIM Register & Register-Stop process 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="===============1331069959==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org This is a multi-part message in MIME format. --===============1331069959== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007D_01C62734.5B0C1920" This is a multi-part message in MIME format. ------=_NextPart_000_007D_01C62734.5B0C1920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, My next question, this is the situation: When a source DR gets multicast packets it encapsulates them and sends it to the RP by unicast. The RP will check, if there doesn't exist receivers for the group, will send a Register-Stop message and also starts within itself for the group. The source DR as to keep sending null-register packets to the RP before the timer expires thereby maintaining the state for the group. Now if a receiver joins the group the RP will send a (S, G, spt) Join to the source DR. Now the source DR sends multicast data to the RP, which in turn will forward it to the receiver's DR through the (*, G, rpt) Join that the receiver's DR had sent earlier. Once the Receiver's DR learns the address of the source, it sends a (S, G, spt) Join directly to the source DR and the source DR will forward multicast traffic directly to the receiver's DR. 1.) Now does the receiver's DR send the prune to the RP tree first? And when does the source DR send a prune to the RP? 2.) Now if this was the only receiver for the group & the traffic is flowing through the source tree then what states will be maintained by the RP for the group, assuming that the source is transmitting?? 3.) And does the RP know that there is direct forwarding of traffic between the source DR and receiver DR? 4.) Is the multicast data forwarded to the RP always encapsulated, even if the RP sends (S, G, spt) Join to the source DR as above??? Cheers Nikhil ------=_NextPart_000_007D_01C62734.5B0C1920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

= ; My next question, this is the = situation:

When a source DR gets multicast packets it encapsulates them and sends it to the RP by unicast. The RP will check, = if there doesn’t exist receivers for the group, will send a = Register-Stop message and also starts within itself for the group. The source DR as to = keep sending null-register packets to the RP before the timer expires thereby maintaining the state for the group. Now if a receiver joins the group = the RP will send a (S, G, spt) Join to the source DR. Now the source DR sends multicast data to the RP, which in turn will forward it to the = receiver’s DR through the (*, G, rpt) Join that the receiver’s DR had sent = earlier. Once the Receiver’s DR learns the address of the source, it sends a (S, = G, spt) Join directly to the source DR and the source DR will forward = multicast traffic directly to the receiver’s = DR.

1.) = Now does the receiver’s DR send the prune to the RP tree first? And = when does the source DR send a prune to the RP?

2.) = Now if this was the only receiver for the group & the traffic is flowing through the source tree then what states will be maintained by the RP = for the group, assuming that the source is = transmitting??

3.) = And does the RP know that there is direct forwarding of traffic between the = source DR and receiver DR?

4.) = Is the multicast data forwarded to the RP always encapsulated, even if the = RP sends (S, G, spt) Join to the source DR as = above???

Cheers

Nikhil

------=_NextPart_000_007D_01C62734.5B0C1920-- --===============1331069959== 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 --===============1331069959==-- From pim-bounces@ietf.org Wed Feb 01 09:00: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 1F4IXG-0005S1-M5; Wed, 01 Feb 2006 09:00:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4IXE-0005Qe-6n for pim@megatron.ietf.org; Wed, 01 Feb 2006 09:00:36 -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 IAA01290 for ; Wed, 1 Feb 2006 08:58:51 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4IiF-0006mE-4s for pim@ietf.org; Wed, 01 Feb 2006 09:12:01 -0500 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 14:00:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [pim] PIM Register & Register-Stop process Date: Wed, 1 Feb 2006 14:00:11 -0000 Message-ID: <986E07666EAE1C459DC81492A7FA4CEA0F19B7@enfimail1.datcon.co.uk> Thread-Topic: [pim] PIM Register & Register-Stop process Thread-Index: AcYnNFddvvt/qJVoTceb5usBAsbvcgAAYCZw From: "David McWalter" To: "Nikhil Ninan" X-OriginalArrivalTime: 01 Feb 2006 14:00:11.0606 (UTC) FILETIME=[D1601F60:01C62737] X-Spam-Score: 0.2 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 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="===============0514504524==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org This is a multi-part message in MIME format. --===============0514504524== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62737.D144BA00" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62737.D144BA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1) This is in the overview, section 3. The DR waits for the SPT data = before pruning off the RPT. .. When the first traffic starts to arrive from the SPT, the DR or upstream router starts to drop the packets for G from S that arrive via the RP tree. In addition, it sends an (S,G) Prune message towards the RP. This is known as an (S,G,rpt) Prune. ... =20 2) The RP will have keepalive timer KAT(S,G) from the Register messages, = plus (*,G,I) and (S,G,rpt,I) state on the downstream interface from the = Join(*,G) and Prune(S,G,rpt) it has received, and continues to receive = periodically. =20 3) No. PIM is pretty much hop-by-hop. PIM routers don't try to work = out the state of remote routers across the network; just adjacent ones. =20 4) No. If the RP joins the SPT, it gets multicast data hop-by-hop just = like anyone else. When it gets the Prune(S,G,rpt), it'll leave the SPT = again and not forward any (S,G) data at all. =20 Try searching for this stuff in the PIM spec. It's all in there. http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-11.txt =20 DMcW. =20 -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of = Nikhil Ninan Sent: 01 February 2006 13:35 To: pim@ietf.org Subject: [pim] PIM Register & Register-Stop process Importance: High Hello, My next question, this is the situation: =20 When a source DR gets multicast packets it encapsulates them and sends = it to the RP by unicast. The RP will check, if there doesn't exist = receivers for the group, will send a Register-Stop message and also = starts within itself for the group. The source DR as to keep sending = null-register packets to the RP before the timer expires thereby = maintaining the state for the group. Now if a receiver joins the group = the RP will send a (S, G, spt) Join to the source DR. Now the source DR = sends multicast data to the RP, which in turn will forward it to the = receiver's DR through the (*, G, rpt) Join that the receiver's DR had = sent earlier. Once the Receiver's DR learns the address of the source, = it sends a (S, G, spt) Join directly to the source DR and the source DR = will forward multicast traffic directly to the receiver's DR. =20 1.) Now does the receiver's DR send the prune to the RP tree first? = And when does the source DR send a prune to the RP? 2.) Now if this was the only receiver for the group & the traffic is = flowing through the source tree then what states will be maintained by = the RP for the group, assuming that the source is transmitting?? 3.) And does the RP know that there is direct forwarding of traffic = between the source DR and receiver DR? 4.) Is the multicast data forwarded to the RP always encapsulated, = even if the RP sends (S, G, spt) Join to the source DR as above??? =20 Cheers Nikhil ------_=_NextPart_001_01C62737.D144BA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

1)=20 This is in the overview, section 3. The DR waits for the SPT data = before=20 pruning off the RPT.

.. When the first traffic starts to = arrive from=20 the SPT, the DR or
upstream router starts to drop the packets for G = from S=20 that arrive via
the RP tree. In addition, it sends an (S,G) = Prune=20 message towards the
RP. This is known as an (S,G,rpt) = Prune. =20 ...

2) The=20 RP will have keepalive timer KAT(S,G) from the Register = messages, plus=20 (*,G,I) and (S,G,rpt,I) state on the downstream interface from the = Join(*,G) and=20 Prune(S,G,rpt) it has received, and continues to receive=20 periodically.

3)=20 No. PIM is pretty much hop-by-hop. PIM routers don't = try=20 to work out the state of remote routers across the network; just = adjacent=20 ones.

4)=20 No. If the RP joins the SPT, it gets multicast data hop-by-hop = just like=20 anyone else. When it gets the Prune(S,G,rpt), it'll leave the SPT = again=20 and not forward any (S,G) data at all.

Try=20 searching for this stuff in the PIM spec. It's all in=20 there.

http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-11.txt

DMcW.

-----Original Message-----
From: pim-bounces@ietf.org = [mailto:pim-bounces@ietf.org]On Behalf Of Nikhil = Ninan
Sent: 01=20 February 2006 13:35
To: pim@ietf.org
Subject: [pim] = PIM=20 Register & Register-Stop process
Importance:=20 High

Hello,

=20 My next question, this is the=20 situation: =20

When a source DR gets = multicast=20 packets it encapsulates them and sends it to the RP by unicast. The RP = will=20 check, if there doesn’t exist receivers for the group, will send a = Register-Stop=20 message and also starts within itself for the group. The source DR as to = keep=20 sending null-register packets to the RP before the timer expires thereby = maintaining the state for the group. Now if a receiver joins the group = the RP=20 will send a (S, G, spt) Join to the source DR. Now the source DR sends = multicast=20 data to the RP, which in turn will forward it to the receiver’s DR = through the=20 (*, G, rpt) Join that the receiver’s DR had sent earlier. Once the = Receiver’s DR=20 learns the address of the source, it sends a (S, G, spt) Join directly = to the=20 source DR and the source DR will forward multicast traffic directly to = the=20 receiver’s DR.

1.) =20 Now does the = receiver’s=20 DR send the prune to the RP tree first? And when does the source DR send = a prune=20 to the RP?

2.) =20 Now if this = was the only=20 receiver for the group & the traffic is flowing through the source = tree then=20 what states will be maintained by the RP for the group, assuming that = the source=20 is transmitting??

3.) =20 And does the = RP know that=20 there is direct forwarding of traffic between the source DR and receiver = DR?

4.) =20 Is the = multicast data=20 forwarded to the RP always encapsulated, even if the RP sends (S, G, = spt) Join=20 to the source DR as above???

Cheers

Nikhil

------_=_NextPart_001_01C62737.D144BA00-- --===============0514504524== 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 --===============0514504524==-- From pim-bounces@ietf.org Mon Feb 06 15:50:28 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 1F6DJc-0007Lc-V9; Mon, 06 Feb 2006 15:50:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6DJF-0007CH-FT; Mon, 06 Feb 2006 15:50:05 -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 PAA22388; Mon, 6 Feb 2006 15:48:23 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6DVS-00057n-Nc; Mon, 06 Feb 2006 16:02:43 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F6DJB-0001D0-MY; Mon, 06 Feb 2006 15:50:01 -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: Mon, 06 Feb 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-06.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 : Anycast-RP using PIM Author(s) : D. Farinacci, Y. Cai Filename : draft-ietf-pim-anycast-rp-06.txt Pages : 12 Date : 2006-2-6 This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. There are no other multicast protocols required to support Anycast- RP, such as MSDP, which has been used traditionally to solve this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-06.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-anycast-rp-06.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-anycast-rp-06.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-2-6134506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-anycast-rp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-anycast-rp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-6134506.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 Tue Feb 07 05:42:43 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 1F6QJ1-0006xf-HI; Tue, 07 Feb 2006 05:42:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6QIz-0006w7-M2 for pim@megatron.ietf.org; Tue, 07 Feb 2006 05:42: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 FAA11578 for ; Tue, 7 Feb 2006 05:40:49 -0500 (EST) Received: from braint.aber.ac.uk ([144.124.16.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6QV9-0002S1-RC for pim@ietf.org; Tue, 07 Feb 2006 05:55:17 -0500 Received: from localhost ([127.0.0.1] helo=braint.aber.ac.uk) by braint.aber.ac.uk with esmtp (Exim 4.54) id 1F6QIa-0001lr-6K for pim@ietf.org; Tue, 07 Feb 2006 10:42:16 +0000 Received: from moin.dcs.aber.ac.uk ([193.60.11.36] helo=aber.ac.uk) by braint.aber.ac.uk with esmtp (Exim 4.54) id 1F6QHk-0001bj-4J; Tue, 07 Feb 2006 10:41:24 +0000 X-Mailer: exmh version 2.0.2 2/24/98 To: pim@ietf.org From: Dave Price Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Feb 2006 10:41:24 +0000 Message-ID: <29466.1139308884@aber.ac.uk> X-Sophos-Scanned: from dap@aber.ac.uk virus scanned OK X-UWA-Mid: 1F6QHk-0001bj-4J X-UWA-Originating-IP: 193.60.11.36 X-UWA-Bounce-Filter: L9zP00bcxL X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: dap@aber.ac.uk Subject: [pim] Minor comment plus question on draft-ietf-pim-anycast-rp-06.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 Dear All, First, minor comment. There is a typo in 3.0 where half way down it says "Ancyast-RP" and not "Anycast-RP". Second, question. The ID does not explicitly consider the position where the DR for a source is actually one of the RPs themselves. E.g. in section 3.0, perhaps RP1 is indeed itself the DR for S1. I think this all still works o.k. though, RP1 would presumably still send the PIM-register to the RPA and thus intercept it itself and behave as described as though it had arrived from another DR. I suppose the only potential problem is if it checked the source of the PIM-register and then acted as though it had arrived "from another RP" in the set... Dave Price --------------------------------------------------------- | David Price, Computer Science | | | | Computer Science, University of Wales, Aberystwyth, | | Penglais Campus, Aberystwyth, Ceredigion, SY23 3DB | | | | Email: dap@aber.ac.uk WWW: http://www.aber.ac.uk/~dap | | Phone: +44 1970 622428 FAX: +44 1970 622455 | --------------------------------------------------------- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Feb 07 13:39:29 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 1F6XkO-0003vr-Tc; Tue, 07 Feb 2006 13:39:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6XkM-0003v7-La for pim@megatron.ietf.org; Tue, 07 Feb 2006 13:39: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 NAA19161 for ; Tue, 7 Feb 2006 13:37:45 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Xwn-0002Dh-6p for pim@ietf.org; Tue, 07 Feb 2006 13:52:18 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 07 Feb 2006 10:39:14 -0800 X-IronPort-AV: i="4.02,95,1139212800"; d="scan'208"; a="254061034:sNHT28634188" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k17IdCQJ021804; Tue, 7 Feb 2006 10:39:12 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k17IdCfU011442; Tue, 7 Feb 2006 10:39:12 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k17IdCMN011437; Tue, 7 Feb 2006 10:39:12 -0800 Date: Tue, 7 Feb 2006 10:39:12 -0800 Message-Id: <200602071839.k17IdCMN011437@dino-lnx.cisco.com> From: Dino Farinacci To: dave.price@aber.ac.uk In-reply-to: <29466.1139308884@aber.ac.uk> (message from Dave Price on Tue, 07 Feb 2006 10:41:24 +0000) Subject: Re: [pim] Minor comment plus question on draft-ietf-pim-anycast-rp-06.txt References: <29466.1139308884@aber.ac.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: pim@ietf.org, dap@aber.ac.uk 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 >> First, minor comment. There is a typo in 3.0 >> where half way down it says "Ancyast-RP" and not "Anycast-RP". Fixed. But not sure this justifies another rev of the spec. I'll let the working group chairs decide. >> E.g. in section 3.0, perhaps RP1 is indeed itself the DR for S1. >> I think this all still works o.k. though, RP1 would >> presumably still send the PIM-register to the RPA and >> thus intercept it itself and behave as described >> as though it had arrived from another DR. Right, but the main PIM spec presumes this. This isn't anything speific to Anycast-PIM. >> I suppose the only potential problem is if it checked the source >> of the PIM-register and then acted as though it had arrived >> "from another RP" in the set... Yes, most implementations, the DR will send the PIM register to the RP address, which is itself. The packet is looped back into an input queue and processed like it came from another system. The same goes for the Register-Stop message that it returns to itself. Thanks, Dino _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Feb 07 17:20:09 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 1F6bBx-0008BR-2h; Tue, 07 Feb 2006 17:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6bBv-0008A5-5c for pim@megatron.ietf.org; Tue, 07 Feb 2006 17:20:07 -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 RAA06990 for ; Tue, 7 Feb 2006 17:18:16 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6bOE-0001fr-Lz for pim@ietf.org; Tue, 07 Feb 2006 17:32:53 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 07 Feb 2006 14:19:47 -0800 X-IronPort-AV: i="4.02,95,1139212800"; d="scan'208"; a="1774315605:sNHT38820432" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k17MJjQP005953; Tue, 7 Feb 2006 14:19:46 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Feb 2006 14:19:45 -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, 7 Feb 2006 11:52:48 -0800 Date: Tue, 7 Feb 2006 11:52:48 -0800 (PST) From: Mike McBride To: Dino Farinacci Subject: Re: [pim] Minor comment plus question on draft-ietf-pim-anycast-rp-06.txt In-Reply-To: <200602071839.k17IdCMN011437@dino-lnx.cisco.com> Message-ID: References: <29466.1139308884@aber.ac.uk> <200602071839.k17IdCMN011437@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 07 Feb 2006 19:52:48.0218 (UTC) FILETIME=[122D6BA0:01C62C20] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: dave.price@aber.ac.uk, pim@ietf.org, dap@aber.ac.uk 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 >>> First, minor comment. There is a typo in 3.0 >>> where half way down it says "Ancyast-RP" and not "Anycast-RP". > > Fixed. But not sure this justifies another rev of the spec. I'll let the > working group chairs decide. Probably not, but thanks for doing it anyway, will make the iesg process proceed that much more smoothly. mike >>> E.g. in section 3.0, perhaps RP1 is indeed itself the DR for S1. >>> I think this all still works o.k. though, RP1 would >>> presumably still send the PIM-register to the RPA and >>> thus intercept it itself and behave as described >>> as though it had arrived from another DR. > > Right, but the main PIM spec presumes this. This isn't anything speific > to Anycast-PIM. > >>> I suppose the only potential problem is if it checked the source >>> of the PIM-register and then acted as though it had arrived >>> "from another RP" in the set... > > Yes, most implementations, the DR will send the PIM register to the RP > address, which is itself. The packet is looped back into an input queue > and processed like it came from another system. The same goes for the > Register-Stop message that it returns to itself. > > Thanks, > Dino > > _______________________________________________ > 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 Feb 07 17:21: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 1F6bDS-0000H0-Mu; Tue, 07 Feb 2006 17:21:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6bDR-0000Gd-HY for pim@megatron.ietf.org; Tue, 07 Feb 2006 17:21: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 RAA07077 for ; Tue, 7 Feb 2006 17:19:51 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6bPm-0001ix-1F for pim@ietf.org; Tue, 07 Feb 2006 17:34:27 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 07 Feb 2006 14:21:23 -0800 X-IronPort-AV: i="4.02,95,1139212800"; d="scan'208"; a="254126275:sNHT30364298" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k17MLIQV006912; Tue, 7 Feb 2006 14:21:23 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Feb 2006 14:21:21 -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, 7 Feb 2006 11:52:20 -0800 Date: Tue, 7 Feb 2006 11:52:20 -0800 (PST) From: Mike McBride To: Dino Farinacci Subject: Re: [pim] Minor comment plus question on draft-ietf-pim-anycast-rp-06.txt In-Reply-To: <200602071839.k17IdCMN011437@dino-lnx.cisco.com> Message-ID: References: <29466.1139308884@aber.ac.uk> <200602071839.k17IdCMN011437@dino-lnx.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 07 Feb 2006 19:52:20.0484 (UTC) FILETIME=[01A58C40:01C62C20] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: dave.price@aber.ac.uk, pim@ietf.org, dap@aber.ac.uk 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 >>> First, minor comment. There is a typo in 3.0 >>> where half way down it says "Ancyast-RP" and not "Anycast-RP". > > Fixed. But not sure this justifies another rev of the spec. I'll let the > working group chairs decide. Probably not, but thanks for doing it anyway, will make the iesg process proceed that much more smoothly. mike >>> E.g. in section 3.0, perhaps RP1 is indeed itself the DR for S1. >>> I think this all still works o.k. though, RP1 would >>> presumably still send the PIM-register to the RPA and >>> thus intercept it itself and behave as described >>> as though it had arrived from another DR. > > Right, but the main PIM spec presumes this. This isn't anything speific > to Anycast-PIM. > >>> I suppose the only potential problem is if it checked the source >>> of the PIM-register and then acted as though it had arrived >>> "from another RP" in the set... > > Yes, most implementations, the DR will send the PIM register to the RP > address, which is itself. The packet is looped back into an input queue > and processed like it came from another system. The same goes for the > Register-Stop message that it returns to itself. > > Thanks, > Dino > > _______________________________________________ > 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 Feb 08 08:38: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 1F6pWd-0004NA-LL; Wed, 08 Feb 2006 08:38:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6pWc-0004M6-TK for pim@megatron.ietf.org; Wed, 08 Feb 2006 08:38: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 IAA22850 for ; Wed, 8 Feb 2006 08:36:45 -0500 (EST) Received: from jj.bangj.com ([198.86.89.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6pjD-0004pz-Ff for pim@ietf.org; Wed, 08 Feb 2006 08:51:28 -0500 Received: from jj.bangj.com (localhost.bangj.com [127.0.0.1]) by jj.bangj.com (Postfix) with ESMTP id DC9CEB842 for ; Wed, 8 Feb 2006 08:40:13 -0500 (EST) To: pim@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <73188.1139406013.1@jj.bangj.com> Date: Wed, 08 Feb 2006 08:40:13 -0500 From: Tom Pusateri Message-Id: <20060208134013.DC9CEB842@jj.bangj.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [pim] Working Group Last Call: PIM MIB 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 We are starting a Working Group Last Call for the PIM MIB. The lastest verison was submitted January 25th. The WGLC will expire at 5:00 PM PST on February 22nd 2006. You can read it via this link: http://www.ietf.org/internet-drafts/draft-ietf-pim-mib-v2-05.txt See David McWalter's previous posts on this list to get more info about the changes. Please send your comments to the PIM list. Thanks, Tom & Mike _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Feb 08 16:33:55 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 1F6wwk-0000Za-Tr; Wed, 08 Feb 2006 16:33:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wwj-0000Yp-HK for pim@megatron.ietf.org; Wed, 08 Feb 2006 16:33:53 -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 QAA05291 for ; Wed, 8 Feb 2006 16:32:02 -0500 (EST) Received: from postal2.ind.alcatel.com ([208.8.0.238] helo=ind.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6x9D-0006ko-Q4 for pim@ietf.org; Wed, 08 Feb 2006 16:46:51 -0500 Received: from mailhub1.ind.alcatel.com (mailhub1.ind.alcatel.com [198.206.181.170]) by ind.alcatel.com (8.12.9/8.12.9/(postal 2.0 [OUT])) with ESMTP id k18LXSRk007479 for ; Wed, 8 Feb 2006 13:33:28 -0800 (PST) X-InterScan: Passed Received: from mailhub1.ind.alcatel.com (localhost [127.0.0.1]) by mailhub1.ind.alcatel.com (8.12.10/8.12.10/(mailhub1 4.1.4 [HUB1])) with ESMTP id k18LXRLq018510 for ; Wed, 8 Feb 2006 13:33:27 -0800 (PST) Received: from slummit.utah.ind.alcatel.com ([128.251.40.12]) by mailhub1.ind.alcatel.com (MailFrontier 4.1.1.5579) with ESMTP; Wed, 08 Feb 2006 13:33:27 -0800 Received: (from lmick@localhost) by slummit.utah.ind.alcatel.com (8.9.3+Sun/8.8.8) id OAA10543 for pim@ietf.org; Wed, 8 Feb 2006 14:33:25 -0700 (MST) Date: Wed, 8 Feb 2006 14:33:25 -0700 From: Lori Mickelson To: pim@ietf.org Subject: Re: [pim] Working Group Last Call: PIM MIB Message-ID: <20060208213325.GA10539@slummit.utah.xylan.com> References: <20060208134013.DC9CEB842@jj.bangj.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060208134013.DC9CEB842@jj.bangj.com> User-Agent: Mutt/1.4.2.1i X-Mlf-Threat: nothreat X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 In order to support Dense Mode, don't you need an object in the pimInterfaceTable that specifies which mode the interface is configured for? Otherwise, how do you know if you're running Sparse or Dense Mode on the interface? Thanks, Lori On Wed, Feb 08, 2006 at 08:40:13AM -0500, Tom Pusateri wrote: > We are starting a Working Group Last Call for the PIM MIB. The lastest > verison was submitted January 25th. > > The WGLC will expire at 5:00 PM PST on February 22nd 2006. > > You can read it via this link: > > http://www.ietf.org/internet-drafts/draft-ietf-pim-mib-v2-05.txt > > See David McWalter's previous posts on this list to get more info > about the changes. > > Please send your comments to the PIM list. > > Thanks, > Tom & 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 Wed Feb 08 16:48:06 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 1F6xAS-00055x-NG; Wed, 08 Feb 2006 16:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6xAP-00054X-KN for pim@megatron.ietf.org; Wed, 08 Feb 2006 16:48:01 -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 QAA06585 for ; Wed, 8 Feb 2006 16:46:19 -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 1F6xN4-0007Le-D8 for pim@ietf.org; Wed, 08 Feb 2006 17:01:07 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2006 13:47:50 -0800 X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208"; a="402512489:sNHT32019740" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k18Llojv020417; Wed, 8 Feb 2006 13:47:50 -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, 8 Feb 2006 13:47:50 -0800 Received: from [192.168.1.4] ([10.21.82.45]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 13:47:50 -0800 In-Reply-To: <20060208213325.GA10539@slummit.utah.xylan.com> References: <20060208134013.DC9CEB842@jj.bangj.com> <20060208213325.GA10539@slummit.utah.xylan.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <55BD293F-BF49-4909-8BCF-D6C92E1CAD9D@cisco.com> Content-Transfer-Encoding: 7bit From: John Zwiebel Subject: Re: [pim] Working Group Last Call: PIM MIB Date: Wed, 8 Feb 2006 13:48:29 -0800 To: Lori Mickelson X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 08 Feb 2006 21:47:50.0287 (UTC) FILETIME=[4E8B51F0:01C62CF9] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Feb 8, 2006, at 1:33 PM, Lori Mickelson wrote: > Otherwise, how do you know if you're running > Sparse or Dense Mode on the interface? > "sparseness" is a property of the group not the router interface. This is why IOS recommends "sparse-dense" mode. Procket did not support dense-mode and so the config command was just "ip pim sparse" Configuring "ip pim dense" is a holdover from PIMv1 where it was up to the router to forward a group using whatever method (sparse or dense) that it wanted to. We quickly realized that was a mistake. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Feb 08 17:51:19 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 1F6y9f-00008D-5v; Wed, 08 Feb 2006 17:51:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6y9d-0008VY-1y for pim@megatron.ietf.org; Wed, 08 Feb 2006 17:51:17 -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 RAA13398 for ; Wed, 8 Feb 2006 17:49:19 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6yM3-0001nJ-UQ for pim@ietf.org; Wed, 08 Feb 2006 18:04:09 -0500 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Feb 2006 22:50:44 +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] Working Group Last Call: PIM MIB Date: Wed, 8 Feb 2006 22:50:44 -0000 Message-ID: <52A0FF47062B0B4C80862F2526E024090C1FCE@enfimail2.datcon.co.uk> Thread-Topic: [pim] Working Group Last Call: PIM MIB Thread-Index: AcYs+ZjfhYhMxKr1RAK31hMMd54ssQAAB+fQ From: "David McWalter" To: "Lori Mickelson" X-OriginalArrivalTime: 08 Feb 2006 22:50:44.0729 (UTC) FILETIME=[18497690:01C62D02] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Hi Lori. Good question. This is an interesting area. I agree with John's answer - PIM mode should be a property of the Group, = not the Interface. PIM-MIB has four objects where PIM mode can be written/read, all below a = particular Group. pimStaticRPPimMode pimGroupMappingPimMode pimStarGPimMode pimSGPimMode So there's no way in PIM-MIB to set/read a particular PIM mode on an = interface. But looking outside of PIM-MIB, RFC2932 (IPMROUTE-STD-MIB) *does* have a = value from IANAipMRouteProtocol readable on each interface. See = ipMRouteInterfaceProtocol in RFC2932. I believe that's wrong. http://www.ietf.org/rfc/rfc2932.txt http://www.iana.org/assignments/ianaiprouteprotocol-mib I'm planning some fixes to RFC2932, among them deprecating = ~InterfaceProtocol. If anyone would like details on that work, see the = following draft and discussion of it in MBONED. (MBONED because it's not = PIM-specific). http://www.ietf.org/internet-drafts/draft-mcwalter-ip-mcast-mib-01.txt Hope that answers your concerns. Dave McW. -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of John Zwiebel Sent: 08 February 2006 21:48 To: Lori Mickelson Cc: pim@ietf.org Subject: Re: [pim] Working Group Last Call: PIM MIB On Feb 8, 2006, at 1:33 PM, Lori Mickelson wrote: > Otherwise, how do you know if you're running > Sparse or Dense Mode on the interface? > "sparseness" is a property of the group not the router interface. This is why IOS recommends "sparse-dense" mode. Procket did not support dense-mode and so the config command was just =20 "ip pim sparse" Configuring "ip pim dense" is a holdover from PIMv1 where it was up =20 to the router to forward a group using whatever method (sparse or dense) =20 that it wanted to. We quickly realized that was a mistake. _______________________________________________ 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 Thu Feb 09 10:44:35 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 1F7DyF-0008Ig-Sw; Thu, 09 Feb 2006 10:44:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7DyE-0008DO-Fn for pim@megatron.ietf.org; Thu, 09 Feb 2006 10:44:34 -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 KAA02831 for ; Thu, 9 Feb 2006 10:42:39 -0500 (EST) Received: from kecgate06.infosysconsulting.com ([61.95.162.82] helo=Kecgate06.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7EAp-0004QN-L1 for pim@ietf.org; Thu, 09 Feb 2006 10:57:37 -0500 Received: from INDHUBBHS02.ad.infosys.com ([192.168.200.82]) by Kecgate06.infosys.com with InterScan Messaging Security Suite; Thu, 09 Feb 2006 21:12:14 +0530 Received: from BLRKECMSG14.ad.infosys.com ([172.22.147.6]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Feb 2006 21:11:55 +0530 Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by BLRKECMSG14.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 21:11:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-06.txt Date: Thu, 9 Feb 2006 21:11:49 +0530 Message-ID: <6031539A3C7B964581EFCE2E205D6EEF844CF5@BLRKECMSG01.ad.infosys.com> Thread-Topic: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-06.txt Thread-Index: AcYrYA9DnlXrSOrlTnyb+5PI1PcD1QCK4dkg From: "bharat_joshi" To: X-OriginalArrivalTime: 09 Feb 2006 15:41:55.0388 (UTC) FILETIME=[5AD157C0:01C62D8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Cc: ycai@cisco.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 Hi All, This is the first time I am reviewing this draft and I have following questions: [There might be some question which has already been discussed so if something have been decided, please let me know] In "Overview" section:=0D * In statement, "The RP address, or a prefix that covers the RP address, is injected", I think RP address we are referring to is Anycast RP address. Right? Can we make it explicit? * Also the injection of unicast route is supposed to be done in all RPs in the Anycast RP set. Right? Can we add this here? In "Mechanism" section: * Can we change "now" in statement "If RP2 decides not to wait, the Register-Stop is sent now" to "immediately". * In point "RP3 creates (S1,G) state so when a receiver joins after S1 starts sending, RP3 can join quickly to the source-tree for S1", does this mean that the multicast traffic for "G" will flow till RP3 even when there are no listeners. Is it correct? Why would we want to do that? In "Observations and Guidelines about this Proposal" section: * In the first point, its mentioned that TTL must be copied from register message received to what the router generates towards other RPs in Anycast RP set. Should not we decrement the TTL before copying it? This is how it should have happened in Unicast Routing of Register message. * Can we add an advantage by suppressing "Register NULL" messages? In section 5.1: * In paragraph 4, it's mentioned that "if a data register or NULL register was received from either a DR or another Anycast-RP. That is, they would send Registers to the other members of the Anycast-RP set." I think this will be done when the Data or NULL register is not not received from a RP in the Anycast RPset. Am I correct? * In paragraph 5, It's mentioned that "Register messages are sent only to those members who does not have MSDP peering". So is there a way to find out if a RP in Anycast RPSet has MSDP peering or not? * Will the Group-RP-Mapping of a group to an Anycast RP address is achieved by static, BSR mechanism etc? Thanks & Regards, Bharat > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Tuesday, February 07, 2006 2:20 AM > To: i-d-announce@ietf.org > Cc: pim@ietf.org > Subject: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-06.txt >=0D > 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. >=0D > Title : Anycast-RP using PIM > Author(s) : D. Farinacci, Y. Cai > Filename : draft-ietf-pim-anycast-rp-06.txt > Pages : 12 > Date : 2006-2-6 >=0D > This specification allows Anycast-RP (Rendezvous Point) to be used > inside a domain that runs Protocol Independent Multicast (PIM) only. > There are no other multicast protocols required to support Anycast- > RP, such as MSDP, which has been used traditionally to solve this > problem. >=0D > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-06.txt >=0D > 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. >=0D >=0D > 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-anycast-rp-06.txt". >=0D > 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 >=0D >=0D > Internet-Drafts can also be obtained by e-mail. >=0D > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pim-anycast-rp-06.txt". >=0D > 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. >=0D >=0D > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. **************** 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 Feb 09 11:38:07 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 1F7Eo3-0008EC-E8; Thu, 09 Feb 2006 11:38:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Eo1-0008Cf-4H for pim@megatron.ietf.org; Thu, 09 Feb 2006 11:38:05 -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 LAA07077 for ; Thu, 9 Feb 2006 11:36:13 -0500 (EST) Received: from postal2.ind.alcatel.com ([208.8.0.238] helo=ind.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7F0h-0006PG-Cr for pim@ietf.org; Thu, 09 Feb 2006 11:51:12 -0500 Received: from mailhub1.ind.alcatel.com (mailhub1.ind.alcatel.com [198.206.181.170]) by ind.alcatel.com (8.12.9/8.12.9/(postal 2.0 [OUT])) with ESMTP id k19GbeRk014129; Thu, 9 Feb 2006 08:37:40 -0800 (PST) X-InterScan: Passed Received: from mailhub1.ind.alcatel.com (localhost [127.0.0.1]) by mailhub1.ind.alcatel.com (8.12.10/8.12.10/(mailhub1 4.1.4 [HUB1])) with ESMTP id k19GbdLq015922; Thu, 9 Feb 2006 08:37:39 -0800 (PST) Received: from slummit.utah.ind.alcatel.com ([128.251.40.12]) by mailhub1.ind.alcatel.com (MailFrontier 4.1.1.5579) with ESMTP; Thu, 09 Feb 2006 08:37:39 -0800 Received: (from lmick@localhost) by slummit.utah.ind.alcatel.com (8.9.3+Sun/8.8.8) id JAA10786; Thu, 9 Feb 2006 09:37:37 -0700 (MST) Date: Thu, 9 Feb 2006 09:37:37 -0700 From: Lori Mickelson To: David McWalter Subject: Re: [pim] Working Group Last Call: PIM MIB Message-ID: <20060209163737.GA10772@slummit.utah.xylan.com> References: <52A0FF47062B0B4C80862F2526E024090C1FCE@enfimail2.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52A0FF47062B0B4C80862F2526E024090C1FCE@enfimail2.datcon.co.uk> User-Agent: Mutt/1.4.2.1i X-Mlf-Threat: nothreat X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Hi Dave and John, Ok. so if PIM mode is a property of the group, how do you get a particular group to be used with dense mode? If we could get an entry into the pimGroupMappingEntry table with a mode of dense, this would explain things for me, but I don't see anywhere in this MIB that allows configuration for a particular group to be dense mode. I'm obviously missing something here. pimStarGPimMode and pimSGPimMode are read-only and pimStaticRPPIMMode only specifies ssm, asm or bidir as options. Also, you only list { ssm(2), asm(3) } for pimSGPimMode. Shouldn't you add dm(5) to the list as well since you do include several DM only objects in this table. Thanks, Lori On Wed, Feb 08, 2006 at 10:50:44PM -0000, David McWalter wrote: > Hi Lori. > > Good question. This is an interesting area. > > I agree with John's answer - PIM mode should be a property of the Group, not the Interface. > > PIM-MIB has four objects where PIM mode can be written/read, all below a particular Group. > pimStaticRPPimMode > pimGroupMappingPimMode > pimStarGPimMode > pimSGPimMode > > So there's no way in PIM-MIB to set/read a particular PIM mode on an interface. > > But looking outside of PIM-MIB, RFC2932 (IPMROUTE-STD-MIB) *does* have a value from IANAipMRouteProtocol readable on each interface. See ipMRouteInterfaceProtocol in RFC2932. I believe that's wrong. > http://www.ietf.org/rfc/rfc2932.txt > http://www.iana.org/assignments/ianaiprouteprotocol-mib > > I'm planning some fixes to RFC2932, among them deprecating ~InterfaceProtocol. If anyone would like details on that work, see the following draft and discussion of it in MBONED. (MBONED because it's not PIM-specific). > http://www.ietf.org/internet-drafts/draft-mcwalter-ip-mcast-mib-01.txt > > Hope that answers your concerns. > Dave McW. > > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of > John Zwiebel > Sent: 08 February 2006 21:48 > To: Lori Mickelson > Cc: pim@ietf.org > Subject: Re: [pim] Working Group Last Call: PIM MIB > > > > On Feb 8, 2006, at 1:33 PM, Lori Mickelson wrote: > > > Otherwise, how do you know if you're running > > Sparse or Dense Mode on the interface? > > > > "sparseness" is a property of the group not the router interface. > > This is why IOS recommends "sparse-dense" mode. > > Procket did not support dense-mode and so the config command was just > "ip pim sparse" > > Configuring "ip pim dense" is a holdover from PIMv1 where it was up > to the > router to forward a group using whatever method (sparse or dense) > that it > wanted to. We quickly realized that was a mistake. > > _______________________________________________ > 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 Thu Feb 09 12:21: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 1F7FUA-0002J7-9K; Thu, 09 Feb 2006 12:21:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7FU8-0002IE-7i for pim@megatron.ietf.org; Thu, 09 Feb 2006 12:21:36 -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 MAA10472 for ; Thu, 9 Feb 2006 12:19:40 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Fgl-0007z4-39 for pim@ietf.org; Thu, 09 Feb 2006 12:34:40 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0BFF32D4AAB for ; Thu, 9 Feb 2006 12:20:59 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18892-01-8 for ; Thu, 9 Feb 2006 12:20:57 -0500 (EST) Received: from vader.nexthop.com (ctbrown.nexthop.com [65.247.36.75]) by aa-mx1.nexthop.com (Postfix) with SMTP id A72662D4AAA for ; Thu, 9 Feb 2006 12:20:57 -0500 (EST) Received: by vader.nexthop.com (sSMTP sendmail emulation); Thu, 9 Feb 2006 12:20:57 -0500 From: "Christopher Thomas Brown" Date: Thu, 9 Feb 2006 12:20:57 -0500 To: pim@ietf.org Subject: Re: [pim] Working Group Last Call: PIM MIB Message-ID: <20060209172057.GA30258@nexthop.com> Mail-Followup-To: pim@ietf.org References: <52A0FF47062B0B4C80862F2526E024090C1FCE@enfimail2.datcon.co.uk> <20060209163737.GA10772@slummit.utah.xylan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060209163737.GA10772@slummit.utah.xylan.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Lori Mickelson initiated a hyperspace jump with: > Hi Dave and John, > > Ok. so if PIM mode is a property of the group, how do you get a particular > group to be used with dense mode? If we could get an entry into > the pimGroupMappingEntry table with a mode of dense, this would explain > things for me, but I don't see anywhere in this MIB that allows > configuration for a particular group to be dense mode. I'm obviously > missing something here. In 'sparse-dense' a group is sparse if an RP is known for the group; otherwise it is dense. This shouldn't be something that is directly settable on the group object. Its a dynamic property. > pimStarGPimMode and pimSGPimMode are read-only and pimStaticRPPIMMode > only specifies ssm, asm or bidir as options. > > Also, you only list { ssm(2), asm(3) } for pimSGPimMode. Shouldn't you > add dm(5) to the list as well since you do include several DM only > objects in this table. If I'm not mistaken tehn asm = sparse-dense. I'm getting the feeling that maybe the working group should publish a document (informational?) on sparse-dense. There are implementations of PIM out there where sparse and dense are mutually exclusive on an interface. Chris _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Feb 09 12:23:51 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 1F7FWJ-0003Wd-Hg; Thu, 09 Feb 2006 12:23:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7FWC-0003QZ-LG for pim@megatron.ietf.org; Thu, 09 Feb 2006 12:23:49 -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 MAA10721 for ; Thu, 9 Feb 2006 12:22:00 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Fj0-00085Z-8M for pim@ietf.org; Thu, 09 Feb 2006 12:37:00 -0500 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 17:23:31 +0000 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] Working Group Last Call: PIM MIB X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 9 Feb 2006 17:23:30 -0000 Message-ID: <52A0FF47062B0B4C80862F2526E024090C1FD5@enfimail2.datcon.co.uk> Thread-Topic: [pim] Working Group Last Call: PIM MIB Thread-Index: AcYtlyYZW+Qb96q+QjuTT8e79BF61QAAD+Kw From: "David McWalter" To: "Lori Mickelson" X-OriginalArrivalTime: 09 Feb 2006 17:23:31.0338 (UTC) FILETIME=[8C497EA0:01C62D9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Cc: "Nicholas, Jonathan - ACD " , 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 Hi Lori. PIM mode and group-to-RP mapping are obtained in the same way. So if we statically configure an RP for the group, the PIM mode gets = configured along with it as pimStaticRPPimMode. Or if RPs are = discovered using BSR, we get an SM/BIDIR bit in the advertised group = address. I imagine Auto-RP and Embedded-RP must have similar = mechanisms. You're quite right that the following three read-only fields must now = allow the value of dm(5). Thanks for spotting that, I'll make sure it = gets fixed. pimStaticRPPimMode pimStarGPimMode pimSGPimMode The field pimGroupMappingPimMode is fine, since we haven't declared a = restricted syntax for it. I guess that still leaves ambiguity in the case where we don't have an = RP, so for groups in the SSM range, and perhaps if implementations are = trying to cope with (S,G) membership for ASM G in the absence of an RP. = In these cases it's not clear from the MIB how an implementation should = pick a PIM mode, and an administrator can't predict behavior by querying = the MIB. In practice this looks like a non-issue, because BIDIR always requires = an RP, and I'm not expecting any hybrid SM/DM implementations ever. We = can also argue that DM is only experimental, and this MIB doesn't intend = to support it fully. However, if anyone needs this resolved then it's not that hard. For = example, we could add a read-only global object to specify whether DM/SM = is used in the SSM range. If anyone has a requirement here, let me = know. I've copied Jonathan because of his interest in getting DM support in = PIM-MIB. Ta, DMcW. -----Original Message----- From: Lori Mickelson [mailto:lmick@ind.alcatel.com] Sent: 09 February 2006 16:38 To: David McWalter Cc: jzwiebel@cisco.com; pim@ietf.org Subject: Re: [pim] Working Group Last Call: PIM MIB Hi Dave and John, Ok. so if PIM mode is a property of the group, how do you get a = particular group to be used with dense mode? If we could get an entry into the pimGroupMappingEntry table with a mode of dense, this would explain things for me, but I don't see anywhere in this MIB that allows configuration for a particular group to be dense mode. I'm obviously missing something here. pimStarGPimMode and pimSGPimMode are read-only and pimStaticRPPIMMode only specifies ssm, asm or bidir as options. Also, you only list { ssm(2), asm(3) } for pimSGPimMode. Shouldn't you add dm(5) to the list as well since you do include several DM only objects in this table. Thanks, Lori On Wed, Feb 08, 2006 at 10:50:44PM -0000, David McWalter wrote: > Hi Lori. >=20 > Good question. This is an interesting area. >=20 > I agree with John's answer - PIM mode should be a property of the = Group, not the Interface. >=20 > PIM-MIB has four objects where PIM mode can be written/read, all below = a particular Group. > pimStaticRPPimMode > pimGroupMappingPimMode > pimStarGPimMode > pimSGPimMode >=20 > So there's no way in PIM-MIB to set/read a particular PIM mode on an = interface. >=20 > But looking outside of PIM-MIB, RFC2932 (IPMROUTE-STD-MIB) *does* have = a value from IANAipMRouteProtocol readable on each interface. See = ipMRouteInterfaceProtocol in RFC2932. I believe that's wrong. > http://www.ietf.org/rfc/rfc2932.txt > http://www.iana.org/assignments/ianaiprouteprotocol-mib >=20 > I'm planning some fixes to RFC2932, among them deprecating = ~InterfaceProtocol. If anyone would like details on that work, see the = following draft and discussion of it in MBONED. (MBONED because it's not = PIM-specific). > http://www.ietf.org/internet-drafts/draft-mcwalter-ip-mcast-mib-01.txt >=20 > Hope that answers your concerns. > Dave McW. >=20 > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of > John Zwiebel > Sent: 08 February 2006 21:48 > To: Lori Mickelson > Cc: pim@ietf.org > Subject: Re: [pim] Working Group Last Call: PIM MIB >=20 >=20 >=20 > On Feb 8, 2006, at 1:33 PM, Lori Mickelson wrote: >=20 > > Otherwise, how do you know if you're running > > Sparse or Dense Mode on the interface? > > >=20 > "sparseness" is a property of the group not the router interface. >=20 > This is why IOS recommends "sparse-dense" mode. >=20 > Procket did not support dense-mode and so the config command was just = > "ip pim sparse" >=20 > Configuring "ip pim dense" is a holdover from PIMv1 where it was up =20 > to the > router to forward a group using whatever method (sparse or dense) =20 > that it > wanted to. We quickly realized that was a mistake. >=20 > _______________________________________________ > 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 Thu Feb 09 12:29:51 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 1F7Fc7-0005ya-5h; Thu, 09 Feb 2006 12:29:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Fc4-0005wT-NV for pim@megatron.ietf.org; Thu, 09 Feb 2006 12:29:48 -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 MAA11438 for ; Thu, 9 Feb 2006 12:28:05 -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 1F7Fot-0008Ng-TY for pim@ietf.org; Thu, 09 Feb 2006 12:43:05 -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 k19HTbhx013815; Thu, 9 Feb 2006 12:29:37 -0500 From: "Jonathan Natale" To: "Christopher Thomas Brown" , Subject: RE: [pim] Working Group Last Call: PIM MIB Date: Thu, 9 Feb 2006 12:29:37 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20060209172057.GA30258@nexthop.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit 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: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org see inline > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of > Christopher Thomas Brown > Sent: Thursday, February 09, 2006 12:21 PM > To: pim@ietf.org > Subject: Re: [pim] Working Group Last Call: PIM MIB > > > Lori Mickelson initiated a hyperspace jump with: > > Hi Dave and John, > > > > Ok. so if PIM mode is a property of the group, how do you get a > particular > > group to be used with dense mode? If we could get an entry into > > the pimGroupMappingEntry table with a mode of dense, this would explain > > things for me, but I don't see anywhere in this MIB that allows > > configuration for a particular group to be dense mode. I'm obviously > > missing something here. > > > In 'sparse-dense' a group is sparse if an RP is known for the group; > otherwise it is dense. This shouldn't be something that is directly > settable on the group object. Its a dynamic property. > > > > pimStarGPimMode and pimSGPimMode are read-only and pimStaticRPPIMMode > > only specifies ssm, asm or bidir as options. > > > > Also, you only list { ssm(2), asm(3) } for pimSGPimMode. Shouldn't you > > add dm(5) to the list as well since you do include several DM only > > objects in this table. > > If I'm not mistaken tehn asm = sparse-dense. > > > I'm getting the feeling that maybe the working group should publish > a document (informational?) on sparse-dense. I agree. > There are implementations > of PIM out there where sparse and dense are mutually exclusive on an > interface. > > Chris > > _______________________________________________ > 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 Thu Feb 09 12:43:53 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 1F7Fpf-00036s-Up; Thu, 09 Feb 2006 12:43:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Fpd-000355-C3 for pim@megatron.ietf.org; Thu, 09 Feb 2006 12:43:49 -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 MAA12609 for ; Thu, 9 Feb 2006 12:42:05 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7G2S-0000Q8-Fv for pim@ietf.org; Thu, 09 Feb 2006 12:57:06 -0500 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 17:43:37 +0000 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] Working Group Last Call: PIM MIB X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 9 Feb 2006 17:43:37 -0000 Message-ID: <52A0FF47062B0B4C80862F2526E024090C1FD6@enfimail2.datcon.co.uk> Thread-Topic: [pim] Working Group Last Call: PIM MIB Thread-Index: AcYtndNRneKKeq6JTy+7qSfQblEICQAAE3NA From: "David McWalter" To: "Christopher Thomas Brown" X-OriginalArrivalTime: 09 Feb 2006 17:43:37.0650 (UTC) FILETIME=[5B4E1920:01C62DA0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Hi Christopher. As far as I know, sparse-dense means 'PIMv1'. Here's the IANA = definition: http://www.iana.org/assignments/ianaiprouteprotocol-mib We're no longer doing PIMv1. PIM-MIB is for PIMv2, and so makes no = mention of sparse-dense. So asm !=3D sparse-dense. PIM-MIB is clear on this point: asm(3) Any Source Multicast (ASM), with PIM Sparse Mode. PIM DM was experimental, and I don't think the PIM WG has any plans to = do anything more with DM. The *minimal* support for DM in PIM-MIB is an exception we are making, = because this appears very easy and people tell me there are significant = benefits for them. Cheers, DMcW. -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of Christopher Thomas Brown Sent: 09 February 2006 17:21 To: pim@ietf.org Subject: Re: [pim] Working Group Last Call: PIM MIB Lori Mickelson initiated a hyperspace jump with: > Hi Dave and John, >=20 > Ok. so if PIM mode is a property of the group, how do you get a = particular > group to be used with dense mode? If we could get an entry into > the pimGroupMappingEntry table with a mode of dense, this would = explain > things for me, but I don't see anywhere in this MIB that allows > configuration for a particular group to be dense mode. I'm obviously > missing something here. In 'sparse-dense' a group is sparse if an RP is known for the group; otherwise it is dense. This shouldn't be something that is directly settable on the group object. Its a dynamic property. > pimStarGPimMode and pimSGPimMode are read-only and pimStaticRPPIMMode > only specifies ssm, asm or bidir as options. >=20 > Also, you only list { ssm(2), asm(3) } for pimSGPimMode. Shouldn't = you > add dm(5) to the list as well since you do include several DM only > objects in this table. If I'm not mistaken tehn asm =3D sparse-dense. I'm getting the feeling that maybe the working group should publish a document (informational?) on sparse-dense. There are implementations of PIM out there where sparse and dense are mutually exclusive on an interface. Chris _______________________________________________ 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 Thu Feb 09 14:00:48 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 1F7H28-0007r0-KB; Thu, 09 Feb 2006 14:00:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7H22-0007pc-Kp for pim@megatron.ietf.org; Thu, 09 Feb 2006 14:00:46 -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 NAA20993 for ; Thu, 9 Feb 2006 13:58:52 -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 1F7HEk-0003NV-ID for pim@ietf.org; Thu, 09 Feb 2006 14:13:51 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 09 Feb 2006 11:00:24 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k19J0DkH023633; Thu, 9 Feb 2006 11:00:24 -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); Thu, 9 Feb 2006 11:00:20 -0800 Received: from [192.168.1.4] ([10.21.97.41]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 11:00:19 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <53927BC9-3B2D-4F92-B3ED-3BE42605195B@cisco.com> Content-Transfer-Encoding: 7bit From: John Zwiebel Subject: Re: [pim] Working Group Last Call: PIM MIB Date: Thu, 9 Feb 2006 11:00:59 -0800 To: "Jonathan Natale" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 09 Feb 2006 19:00:19.0555 (UTC) FILETIME=[12411330:01C62DAB] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Christopher Thomas Brown , 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 Feb 9, 2006, at 9:29 AM, Jonathan Natale wrote: >> >> >> I'm getting the feeling that maybe the working group should publish >> a document (informational?) on sparse-dense. > I agree. Perhaps, but be aware that "sparse-dense" is a cisco specific way of configuring its router, is only there because that was how the transition from pimv1 to pimv2 was supported, and isn't a term used in any IETF document that I'm aware of. The information document would basically say: If there is no known RP for a multicast group, it is treated as a dense-mode group - by _some_ implementations. I say "some" because not all vendors implement dense-mode. It has proven to be problematic and any application can use sparse or bidir just as easily. I'm not saying that no one uses dense-mode, just that AFAIK the amount of deployed dense-mode is quite low. 2cents follows... IMHO, ssm and bidir are where the community should be placing its focus. I agree that there are some applications where it is "nice" to be able to use sparse-mode so receivers don't have to know the specific source, but I think it would be "better" to implement an alternate "source DNS" capability that is outside of PIM and does not involve the network in storing source information. (ie it should be in a real database somewhere on a real server.) That way receivers can control which sources they want to receive from using more information than just the multicast group. For example, a DNS-like source-name server (for want of a better term) could cache all the SAP information available on a specific source. Receivers would join to just those sources that were providing exactly what the receiver desired (using SSM). In those cases where you know that the multicast group is tightly controlled such that there is no way that sources will be sending anything but the desired information, use bidir. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Feb 09 14:37:56 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 1F7Hc4-0007XG-2r; Thu, 09 Feb 2006 14:37:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Hc2-0007WO-GK for pim@megatron.ietf.org; Thu, 09 Feb 2006 14:37:54 -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 OAA23535 for ; Thu, 9 Feb 2006 14:36:00 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Hog-0004bR-Lz for pim@ietf.org; Thu, 09 Feb 2006 14:50:59 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 748222D4947 for ; Thu, 9 Feb 2006 14:37:19 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20826-02-19 for ; Thu, 9 Feb 2006 14:37:18 -0500 (EST) Received: from vader.nexthop.com (ctbrown.nexthop.com [65.247.36.75]) by aa-mx1.nexthop.com (Postfix) with SMTP id 1BB522D4957 for ; Thu, 9 Feb 2006 14:37:18 -0500 (EST) Received: by vader.nexthop.com (sSMTP sendmail emulation); Thu, 9 Feb 2006 14:37:18 -0500 From: "Christopher Thomas Brown" Date: Thu, 9 Feb 2006 14:37:18 -0500 To: pim@ietf.org Subject: Re: [pim] Working Group Last Call: PIM MIB Message-ID: <20060209193718.GB30258@nexthop.com> Mail-Followup-To: pim@ietf.org References: <52A0FF47062B0B4C80862F2526E024090C1FD6@enfimail2.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52A0FF47062B0B4C80862F2526E024090C1FD6@enfimail2.datcon.co.uk> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 David McWalter initiated a hyperspace jump with: > Hi Christopher. > > As far as I know, sparse-dense means 'PIMv1'. Here's the IANA definition: > http://www.iana.org/assignments/ianaiprouteprotocol-mib The two leading brands of router vendors (and probably others) implement a hybrid sparse-dense with PIMv2. In this mode a group is sparse (or Bi-dir) if an RP is known for the group; otherwise, it is dense. > > We're no longer doing PIMv1. PIM-MIB is for PIMv2, and so makes no mention of sparse-dense. Yeah, but several vendors implement a sparse-dense. Which was my main point. Should the WG document this type of use at least as informational? > So asm != sparse-dense. PIM-MIB is clear on this point: > asm(3) Any Source Multicast (ASM), with PIM Sparse > Mode. I don't think the bare word 'asm' should be used here. Dense and DVMRP are ASM protocols as well. Even though you explicitly define it you will have people like me that glance over it and get confused when seeing a word like 'asm'. Maybe renaming 'ssm' to 'sparse-ssm' and 'asm' to 'sparse-asm' make things clearer and consistent? > > PIM DM was experimental, and I don't think the PIM WG has any plans to do anything more with DM. > > The *minimal* support for DM in PIM-MIB is an exception we are making, because this appears very easy and people tell me there are significant benefits for them. The benefit is that its better than writing an enterprise mib for dm. :) Chris _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Feb 09 14:50:19 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 1F7Ho3-0003Um-Lc; Thu, 09 Feb 2006 14:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Ho2-0003Sh-GG for pim@megatron.ietf.org; Thu, 09 Feb 2006 14:50: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 OAA24431 for ; Thu, 9 Feb 2006 14:48:36 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7I0t-00052V-SZ for pim@ietf.org; Thu, 09 Feb 2006 15:03:36 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9D08B2D483C for ; Thu, 9 Feb 2006 14:49:58 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21342-01 for ; Thu, 9 Feb 2006 14:49:57 -0500 (EST) Received: from vader.nexthop.com (ctbrown.nexthop.com [65.247.36.75]) by aa-mx1.nexthop.com (Postfix) with SMTP id 3EB4F2D482A for ; Thu, 9 Feb 2006 14:49:57 -0500 (EST) Received: by vader.nexthop.com (sSMTP sendmail emulation); Thu, 9 Feb 2006 14:49:57 -0500 From: "Christopher Thomas Brown" Date: Thu, 9 Feb 2006 14:49:57 -0500 To: pim@ietf.org Subject: Re: [pim] Working Group Last Call: PIM MIB Message-ID: <20060209194957.GC30258@nexthop.com> Mail-Followup-To: pim@ietf.org References: <53927BC9-3B2D-4F92-B3ED-3BE42605195B@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53927BC9-3B2D-4F92-B3ED-3BE42605195B@cisco.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 John Zwiebel wrote: > > On Feb 9, 2006, at 9:29 AM, Jonathan Natale wrote: > > >> > >> > >>I'm getting the feeling that maybe the working group should publish > >>a document (informational?) on sparse-dense. > >I agree. > > Perhaps, but be aware that "sparse-dense" is a cisco specific way of > configuring its router, is only there because that was how the > transition > from pimv1 to pimv2 was supported, and isn't a term used in any IETF > document that I'm aware of. Not only Cisco has implemented this. If I'm not mistaken then Juniper implements this, I've encountered customer interest in it from time to time. > The information document would basically say: > > If there is no known RP for a multicast group, it is treated as a > dense-mode group - by _some_ implementations. Yeah, it would be fairly short. It might be nice to have some text on how a sparse-to-dense or dense-to-sparse transition should be handled. Chris _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Feb 09 15:20:10 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 1F7IGw-00062J-QD; Thu, 09 Feb 2006 15:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7IGg-000601-Iu for pim@megatron.ietf.org; Thu, 09 Feb 2006 15:20: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 PAA26663 for ; Thu, 9 Feb 2006 15:18:03 -0500 (EST) Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7ITN-0005yj-SN for pim@ietf.org; Thu, 09 Feb 2006 15:33:04 -0500 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 20:19:27 +0000 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] Working Group Last Call: PIM MIB X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 9 Feb 2006 20:19:27 -0000 Message-ID: <52A0FF47062B0B4C80862F2526E024090C1FD7@enfimail2.datcon.co.uk> Thread-Topic: [pim] Working Group Last Call: PIM MIB Thread-Index: AcYtsHHwfnQEx3ciTBmJ2wO5xn6wKwAAkeOw From: "David McWalter" To: "Christopher Thomas Brown" , "John Zwiebel" X-OriginalArrivalTime: 09 Feb 2006 20:19:27.0731 (UTC) FILETIME=[20633C30:01C62DB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 Chris, Thanks for all that. New information for me. John wrote: > The information document would basically say: >=20 > If there is no known RP for a multicast group, it is treated as a > dense-mode group - by _some_ implementations. This behavior seems pretty interesting to administrators, so perhaps I = should make it readable from the standard MIB. How about I add a read-only field (per-interface?) that specifies what = pim mode the router will use in the absence of RP config. If some = implementations want to use the object as a read-write, then fine, they = can. The description can also explain that the usual source of the PIM = mode is from the RP configuration, by pointing at = pimGroupMappingPimMode. Would that standardize the behavior (and get this information published) = in an acceptable way? Dave McW. -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of Christopher Thomas Brown Sent: 09 February 2006 19:37 To: pim@ietf.org Subject: Re: [pim] Working Group Last Call: PIM MIB David McWalter initiated a hyperspace jump with: > Hi Christopher. >=20 > As far as I know, sparse-dense means 'PIMv1'. Here's the IANA = definition: > http://www.iana.org/assignments/ianaiprouteprotocol-mib The two leading brands of router vendors (and probably others) implement = a hybrid sparse-dense with PIMv2. In this mode a group is sparse (or Bi-dir) if an RP is known for the group; otherwise, it is dense. >=20 > We're no longer doing PIMv1. PIM-MIB is for PIMv2, and so makes no = mention of sparse-dense. Yeah, but several vendors implement a sparse-dense. Which was my main point. Should the WG document this type of use at least as = informational? > So asm !=3D sparse-dense. PIM-MIB is clear on this point: > asm(3) Any Source Multicast (ASM), with PIM Sparse > Mode. I don't think the bare word 'asm' should be used here. Dense and DVMRP = are ASM protocols as well. Even though you explicitly define it you will have people like me that glance over it and get confused when seeing a word like 'asm'. Maybe renaming 'ssm' to 'sparse-ssm' and 'asm' to 'sparse-asm' make things clearer and consistent? >=20 > PIM DM was experimental, and I don't think the PIM WG has any plans to = do anything more with DM. >=20 > The *minimal* support for DM in PIM-MIB is an exception we are making, = because this appears very easy and people tell me there are significant = benefits for them. The benefit is that its better than writing an enterprise mib for dm. :) Chris _______________________________________________ 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 Thu Feb 09 15:42: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 1F7IcQ-0007PN-Hs; Thu, 09 Feb 2006 15:42:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7IcP-0007OS-4v for pim@megatron.ietf.org; Thu, 09 Feb 2006 15:42: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 PAA28120 for ; Thu, 9 Feb 2006 15:40:28 -0500 (EST) Received: from jj.bangj.com ([198.86.89.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Ip5-0006fi-JR for pim@ietf.org; Thu, 09 Feb 2006 15:55:29 -0500 Received: from jj.bangj.com (localhost.bangj.com [127.0.0.1]) by jj.bangj.com (Postfix) with ESMTP id 61C13B842 for ; Thu, 9 Feb 2006 15:43:57 -0500 (EST) To: pim@ietf.org Subject: Re: [pim] Working Group Last Call: PIM MIB In-Reply-To: Message from "Christopher Thomas Brown" of "Thu, 09 Feb 2006 14:49:57 EST." <20060209194957.GC30258@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79085.1139517837.1@jj.bangj.com> Date: Thu, 09 Feb 2006 15:43:57 -0500 From: Tom Pusateri Message-Id: <20060209204357.61C13B842@jj.bangj.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 If people want to implement Dense mode, that is their choice. But as far as the PIM WG is concerned, we have no further interest in it. That was clear by how hard it was to progress the dense mode document. No one would even review it. If it wasn't for Jonathan, the document would have just died. There is maybe a handful of people in the world who care. Those small number of people who have interest in dense mode can spend their time working on it as private submissions but unless the feelings of the majority of the PIM working group change drastically in the future, Dense mode is now outside the scope of the working group. I struggle with any support at all for Dense mode in the MIB. I suspect it will have to be taken out in order to advance it to Proposed Standard since the Dense Mode document is an Experimental Standard. We need to be looking forward and not back. We certainly don't need to write any new documents about things like sparse-dense mode. Those are implementation choices and the vendors can document those as they see fit. Sorry if this sounds harsh. We just need to move on. Thanks, Tom In message <20060209194957.GC30258@nexthop.com> you write: >John Zwiebel wrote: >> >> On Feb 9, 2006, at 9:29 AM, Jonathan Natale wrote: >> >> >> >> >> >> >>I'm getting the feeling that maybe the working group should publish >> >>a document (informational?) on sparse-dense. >> >I agree. >> >> Perhaps, but be aware that "sparse-dense" is a cisco specific way of >> configuring its router, is only there because that was how the >> transition >> from pimv1 to pimv2 was supported, and isn't a term used in any IETF >> document that I'm aware of. > > >Not only Cisco has implemented this. If I'm not mistaken then >Juniper implements this, I've encountered customer interest in it >from time to time. > > >> The information document would basically say: >> >> If there is no known RP for a multicast group, it is treated as a >> dense-mode group - by _some_ implementations. > >Yeah, it would be fairly short. It might be nice to have some text >on how a sparse-to-dense or dense-to-sparse transition should be >handled. > > >Chris > >_______________________________________________ >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 Thu Feb 09 15:50: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 1F7IkK-0002Hy-BZ; Thu, 09 Feb 2006 15:50:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Ijs-00023h-9y; Thu, 09 Feb 2006 15:50:05 -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 PAA28853; Thu, 9 Feb 2006 15:48:20 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Iwj-00076M-AO; Thu, 09 Feb 2006 16:03:21 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F7Ijq-0000Lv-Cm; Thu, 09 Feb 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: Thu, 09 Feb 2006 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-07.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 : Anycast-RP using PIM Author(s) : D. Farinacci, Y. Cai Filename : draft-ietf-pim-anycast-rp-07.txt Pages : 12 Date : 2006-2-9 This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. There are no other multicast protocols required to support Anycast- RP, such as MSDP, which has been used traditionally to solve this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-07.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-anycast-rp-07.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-anycast-rp-07.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-2-9143702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-anycast-rp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-anycast-rp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-9143702.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 Thu Feb 09 15:53:00 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 1F7Imh-0002cn-VH; Thu, 09 Feb 2006 15:52:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Img-0002cH-5u for pim@megatron.ietf.org; Thu, 09 Feb 2006 15:52:58 -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 PAA29073 for ; Thu, 9 Feb 2006 15:51:07 -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 1F7IzO-0007Ba-Ue for pim@ietf.org; Thu, 09 Feb 2006 16:06:08 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2006 12:52:37 -0800 X-IronPort-AV: i="4.02,101,1139212800"; d="scan'208"; a="403021885:sNHT30627896" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k19Kqbjt016623 for ; Thu, 9 Feb 2006 12:52:37 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA01079 for pim@ietf.org; Thu, 9 Feb 2006 12:52:34 -0800 (PST) Date: Thu, 9 Feb 2006 12:52:34 -0800 From: Toerless Eckert To: pim@ietf.org Subject: Re: [pim] Working Group Last Call: PIM MIB Message-ID: <20060209125234.J16639@cisco.com> References: <53927BC9-3B2D-4F92-B3ED-3BE42605195B@cisco.com> <20060209194957.GC30258@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060209194957.GC30258@nexthop.com>; from ctbrown@nexthop.com on Thu, Feb 09, 2006 at 02:49:57PM -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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, Feb 09, 2006 at 02:49:57PM -0500, Christopher Thomas Brown wrote: > > Perhaps, but be aware that "sparse-dense" is a cisco specific way of > > configuring its router, is only there because that was how the > > transition > > from pimv1 to pimv2 was supported, and isn't a term used in any IETF > > document that I'm aware of. > > Not only Cisco has implemented this. If I'm not mistaken then > Juniper implements this, I've encountered customer interest in it > from time to time. There's no IETF definition for what this "sparse-dense" mode means, and if one where to write one you would first figure out that word was badly choosen anyhow ("all-modes" would have been more appropriate) and/or it would conflight with the IETF defined behavior of sparse mode. There's a lot of customer interest in stuff they have read in old manual and don't understand. Which typically isn't really a customer issue but a bad-vendor-documentation issue. It only becomes a mess when the feedback loop closes by which stuff the customer didn't understand is now being put as input into cfuture vendor work. So let's not do this. Cheers Toerless _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Feb 09 19:26:52 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 1F7M7g-0002j0-MD; Thu, 09 Feb 2006 19:26:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7M7f-0002gp-1e for pim@megatron.ietf.org; Thu, 09 Feb 2006 19:26:51 -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 TAA26047 for ; Thu, 9 Feb 2006 19:25:08 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7MKX-0001Z6-EK for pim@ietf.org; Thu, 09 Feb 2006 19:40:11 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 225E32D48B3 for ; Thu, 9 Feb 2006 19:26:27 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25658-01-2 for ; Thu, 9 Feb 2006 19:26:25 -0500 (EST) Received: from vader.nexthop.com (ctbrown.nexthop.com [65.247.36.75]) by aa-mx1.nexthop.com (Postfix) with SMTP id BEC0F2D4890 for ; Thu, 9 Feb 2006 19:26:25 -0500 (EST) Received: by vader.nexthop.com (sSMTP sendmail emulation); Thu, 9 Feb 2006 19:26:26 -0500 From: "Christopher Thomas Brown" Date: Thu, 9 Feb 2006 19:26:26 -0500 To: pim@ietf.org Subject: Re: [pim] Working Group Last Call: PIM MIB Message-ID: <20060210002626.GA31053@nexthop.com> Mail-Followup-To: pim@ietf.org References: <20060209194957.GC30258@nexthop.com> <20060209204357.61C13B842@jj.bangj.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060209204357.61C13B842@jj.bangj.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Tom Pusateri initiated a hyperspace jump with: > I struggle with any support at all for Dense mode in the MIB. > I suspect it will have to be taken out in order to advance it > to Proposed Standard since the Dense Mode document is an > Experimental Standard. Is this the relavant constraint? RFC 2026 s4.2.4: "Note: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies." So what qualifies for abnormal? It would be nice if those of us who implement dm don't have to rewrite some of the pim mib as an enterprise mib for a few objects. Just nice, not really a necessity though. > We need to be looking forward and not back. We certainly don't > need to write any new documents about things like sparse-dense > mode. Those are implementation choices and the vendors can > document those as they see fit. > > Sorry if this sounds harsh. We just need to move on. So I take it that you don't want anyone to volunteer for this. :) I only brought this up because the MIB seems to be going in the direction that the sparseness-bidirness vs denseness of a group is a property of the group, which is only true if there is such a thing as 'sparse-dense'. Nothing this wg has produced documents this except for potentially this MIB, which is a poor place to do that. With dm, sm and bidir documented as they currently are by this wg, one could have a pmbr which serviced both a 'dense-mode-only' domain and a 'sparse&bidir-only' domain. On such a mythical router, groups would be sparse or bidir on the later set of interfaces and dense on the former. Upon further reflection the way I see it is that sparse vs dense interactions are an undocumented confusing mess. As much as I would like to see dm values in the mib, I would not like to see the mib further some interpretation of the mess without documenting that interpretation. Lacking such documentation, I think it would just be better if dm support is dropped from the mib. Chris _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Feb 09 22:33:10 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 1F7P1w-0004hW-EI; Thu, 09 Feb 2006 22:33:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7P1r-0004dx-0K for pim@megatron.ietf.org; Thu, 09 Feb 2006 22:33:03 -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 WAA06836 for ; Thu, 9 Feb 2006 22:31:19 -0500 (EST) Received: from sfovwl03.infosys.com ([216.251.50.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7PEk-0006iQ-TE for pim@ietf.org; Thu, 09 Feb 2006 22:46:24 -0500 Received: from INDHUBBHS02.ad.infosys.com ([192.168.200.82]) by SFOVWL03.infosys.com with InterScan Messaging Security Suite; Thu, 09 Feb 2006 19:27:04 -0800 Received: from BLRKECMSG14.ad.infosys.com ([172.22.147.6]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 10 Feb 2006 09:00:29 +0530 Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by BLRKECMSG14.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 09:00:28 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [pim] Working Group Last Call: PIM MIB Date: Fri, 10 Feb 2006 09:00:27 +0530 Message-ID: <6031539A3C7B964581EFCE2E205D6EEF844D0B@BLRKECMSG01.ad.infosys.com> Thread-Topic: [pim] Working Group Last Call: PIM MIB Thread-Index: AcYt2TloabydUWmdQJeEGTdpVV9ljAAGHDsg From: "bharat_joshi" To: "Christopher Thomas Brown" X-OriginalArrivalTime: 10 Feb 2006 03:30:28.0631 (UTC) FILETIME=[56AF6A70:01C62DF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Please see in line. >=0D > Tom Pusateri initiated a hyperspace jump with: > > I struggle with any support at all for Dense mode in the MIB. > > I suspect it will have to be taken out in order to advance it > > to Proposed Standard since the Dense Mode document is an > > Experimental Standard. >=0D > Is this the relavant constraint? > RFC 2026 s4.2.4: > "Note: Standards track specifications normally must not depend on > other standards track specifications which are at a lower maturity > level or on non standards track specifications other than > referenced specifications from other standards bodies." >=0D > So what qualifies for abnormal? >=0D > It would be nice if those of us who implement dm don't have to > rewrite some of the pim mib as an enterprise mib for a few objects. > Just nice, not really a necessity though. >=0D > > We need to be looking forward and not back. We certainly don't > > need to write any new documents about things like sparse-dense > > mode. Those are implementation choices and the vendors can > > document those as they see fit. > > > > Sorry if this sounds harsh. We just need to move on. >=0D > So I take it that you don't want anyone to volunteer for this. :) >=0D > I only brought this up because the MIB seems to be going in the direction > that the sparseness-bidirness vs denseness of a group is a property of > the group, which is only true if there is such a thing as 'sparse-dense'. > Nothing this wg has produced documents this except for potentially this > MIB, > which is a poor place to do that. >=0D > With dm, sm and bidir documented as they currently are by this wg, > one could have a pmbr which serviced both a 'dense-mode-only' domain and > a 'sparse&bidir-only' domain. On such a mythical router, groups would be > sparse or bidir on the later set of interfaces and dense on the former. >=0D > Upon further reflection the way I see it is that sparse vs dense > interactions are an undocumented confusing mess. As much as I would > like to see dm values in the mib, I would not like to see the mib > further some interpretation of the mess without documenting that > interpretation. Lacking such documentation, I think it would > just be better if dm support is dropped from the mib. Hi, I think we have completed a full circle on whether we want to support PIM DM objects in this MIB or not. When we started, Jonathan had added PIM DM objects to the first PIM MIB draft. Later we removed it thinking that this may not be the right place to add these objects and should be moved to another MIB draft. We again added it after seeing Jonathan's PIM DM Objects as they were very small in numbers and no one objected to it. So let us figure out whether someone would really want this before deciding anything on this. 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 Fri Feb 10 03:19: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 1F7TVI-0006hU-Gv; Fri, 10 Feb 2006 03:19:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7TVH-0006gB-BR for pim@megatron.ietf.org; Fri, 10 Feb 2006 03:19: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 DAA27965 for ; Fri, 10 Feb 2006 03:18:00 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7TiE-0007Sx-3w for pim@ietf.org; Fri, 10 Feb 2006 03:33:07 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 10 Feb 2006 00:19:33 -0800 X-IronPort-AV: i="4.02,101,1139212800"; d="scan'208"; a="254680783:sNHT30954110" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1A8JWc1017109; Fri, 10 Feb 2006 00:19:32 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k1A8JWxc011443; Fri, 10 Feb 2006 00:19:32 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k1A8JWDg011439; Fri, 10 Feb 2006 00:19:32 -0800 Date: Fri, 10 Feb 2006 00:19:32 -0800 Message-Id: <200602100819.k1A8JWDg011439@dino-lnx.cisco.com> From: Dino Farinacci To: bharat_joshi@infosys.com In-reply-to: <6031539A3C7B964581EFCE2E205D6EEF844CF5@BLRKECMSG01.ad.infosys.com> (bharat_joshi@infosys.com) Subject: Re: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-06.txt References: <6031539A3C7B964581EFCE2E205D6EEF844CF5@BLRKECMSG01.ad.infosys.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ycai@cisco.com, 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 >> In "Overview" section: >> * In statement, "The RP address, or a prefix that covers the RP address, >> is injected", I think RP address we are referring to is Anycast RP >> address. Right? Can we make it explicit? Yes. >> * Also the injection of unicast route is supposed to be done in all RPs >> in the Anycast RP set. Right? Can we add this here? That is implicit or else there would be no reachability to the RP. >> In "Mechanism" section: >> * Can we change "now" in statement "If RP2 decides not to wait, the >> Register-Stop is sent now" to "immediately". I think it's too late to make changes. Last call has past. >> * In point "RP3 creates (S1,G) state so when a receiver joins after S1 >> starts sending, RP3 can join quickly to the source-tree for S1", does >> this mean that the multicast traffic for "G" will flow till RP3 even >> when there are no listeners. Is it correct? Why would we want to do >> that? No it doesn't. when the Regiser is received and there is no (*,G) state, or there is (*,G) state with an empty oif-list, a Join is *not* sent towards S1. >> In "Observations and Guidelines about this Proposal" section: >> * In the first point, its mentioned that TTL must be copied from >> register message received to what the router generates towards other RPs >> in Anycast RP set. Should not we decrement the TTL before copying it? >> This is how it should have happened in Unicast Routing of Register >> message. Yes, it is assumed to be decrmented in the IP layer when it was received. >> * Can we add an advantage by suppressing "Register NULL" messages? This was suggested before. We decided to not do this. >> In section 5.1: >> * In paragraph 4, it's mentioned that "if a data register or NULL >> register was received from either a DR or another Anycast-RP. That is, >> they would send Registers to the other members of the Anycast-RP set." I >> think this will be done when the Data or NULL register is not not >> received from a RP in the Anycast RPset. Am I correct? What the paragraph and the one before it is saying if if all anycast RPs do not have external MSDP peering connections, then the ones that don't will get packets via a Register from the ones that do have extenral MSDP peering connections. This needs to be configured before if there is more than one, you don't want duplicate packets to go to all anycast-RPs (the ones without the MSDP peerings). >> * In paragraph 5, It's mentioned that "Register messages are sent only >> to those members who does not have MSDP peering". So is there a way to >> find out if a RP in Anycast RPSet has MSDP peering or not? Well, you could if there were active sources in the domain. That is, the source that registers to one RP, which would send an SA for, would be seen by the other RP, from it's external MSDP peering. It would see that the SA came from it's own AS. >> * Will the Group-RP-Mapping of a group to an Anycast RP address is >> achieved by static, BSR mechanism etc? Any of static, BSR, or Auto-RP. Thanks for you comments, Dino _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Feb 10 03:53: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 1F7U2D-0001Y7-7Y; Fri, 10 Feb 2006 03:53:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7U2B-0001WV-TI for pim@megatron.ietf.org; Fri, 10 Feb 2006 03:53: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 DAA29819 for ; Fri, 10 Feb 2006 03:51:50 -0500 (EST) Received: from sfovwl03.inf.com ([216.251.50.9] helo=SFOVWL03.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7UEz-00006s-JR for pim@ietf.org; Fri, 10 Feb 2006 04:06:58 -0500 Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by SFOVWL03.infosys.com with InterScan Messaging Security Suite; Fri, 10 Feb 2006 00:47:40 -0800 Received: from BLRKECMSG04.ad.infosys.com ([172.25.213.134]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 10 Feb 2006 14:21:05 +0530 Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by BLRKECMSG04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 14:21:04 +0530 Received: from osfr-173.local ([192.168.101.134]) by BLRKECMSG01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 14:21:04 +0530 Subject: Re: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-06.txt From: Bharat Joshi To: Dino Farinacci In-Reply-To: <200602100819.k1A8JWDg011439@dino-lnx.cisco.com> References: <6031539A3C7B964581EFCE2E205D6EEF844CF5@BLRKECMSG01.ad.infosys.c om> <200602100819.k1A8JWDg011439@dino-lnx.cisco.com> Content-Type: text/plain Organization: Infosys Technologies Ltd Date: Fri, 10 Feb 2006 14:21:02 +0530 Message-Id: <1139561462.2729.56.camel@magadha> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 08:51:04.0654 (UTC) FILETIME=[203F96E0:01C62E1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Cc: ycai@cisco.com, 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 Hi Dino, Thanks for your response. I am really sorry that I did not get time to review it before the last call. Anyway If you feel that the changes suggested below will help in improving the readability of the document than you can do it. Please see my answers in line. Thanks & Regards, Bharat On Fri, 2006-02-10 at 00:19 -0800, Dino Farinacci wrote: > >> In "Overview" section: > >> * In statement, "The RP address, or a prefix that covers the RP address, > >> is injected", I think RP address we are referring to is Anycast RP > >> address. Right? Can we make it explicit? > > Yes. > So would you want to make it explicit? This will help reader and reviewer of this document. > >> * Also the injection of unicast route is supposed to be done in all RPs > >> in the Anycast RP set. Right? Can we add this here? > > That is implicit or else there would be no reachability to the RP. > Ok. > >> In "Mechanism" section: > >> * Can we change "now" in statement "If RP2 decides not to wait, the > >> Register-Stop is sent now" to "immediately". > > I think it's too late to make changes. Last call has past. > But if it make things easier, I think it should be done. Anyway its your call. > >> * In point "RP3 creates (S1,G) state so when a receiver joins after S1 > >> starts sending, RP3 can join quickly to the source-tree for S1", does > >> this mean that the multicast traffic for "G" will flow till RP3 even > >> when there are no listeners. Is it correct? Why would we want to do > >> that? > > No it doesn't. when the Regiser is received and there is no (*,G) state, > or there is (*,G) state with an empty oif-list, a Join is *not* sent > towards S1. > Ok. > >> In "Observations and Guidelines about this Proposal" section: > >> * In the first point, its mentioned that TTL must be copied from > >> register message received to what the router generates towards other RPs > >> in Anycast RP set. Should not we decrement the TTL before copying it? > >> This is how it should have happened in Unicast Routing of Register > >> message. > > Yes, it is assumed to be decrmented in the IP layer when it was received. > I think we should make it more explicit in the document. > >> * Can we add an advantage by suppressing "Register NULL" messages? > > This was suggested before. We decided to not do this. > Was there any specific reason for not to do this? > >> In section 5.1: > >> * In paragraph 4, it's mentioned that "if a data register or NULL > >> register was received from either a DR or another Anycast-RP. That is, > >> they would send Registers to the other members of the Anycast-RP set." I > >> think this will be done when the Data or NULL register is not not > >> received from a RP in the Anycast RPset. Am I correct? > > What the paragraph and the one before it is saying if if all anycast RPs > do not have external MSDP peering connections, then the ones that don't > will get packets via a Register from the ones that do have extenral > MSDP peering connections. This needs to be configured before if there is > more than one, you don't want duplicate packets to go to all anycast-RPs > (the ones without the MSDP peerings). > You mean to say that this information [whether a RP have external MSDP peering] needs to be configured statically on each RPs in the Anycast RP set. If yes, can we add this information to the document? > >> * In paragraph 5, It's mentioned that "Register messages are sent only > >> to those members who does not have MSDP peering". So is there a way to > >> find out if a RP in Anycast RPSet has MSDP peering or not? > > Well, you could if there were active sources in the domain. That is, the > source that registers to one RP, which would send an SA for, would be > seen by the other RP, from it's external MSDP peering. It would see that > the SA came from it's own AS. As you mentioned above, this information can be configured on the RPs? > > >> * Will the Group-RP-Mapping of a group to an Anycast RP address is > >> achieved by static, BSR mechanism etc? > > Any of static, BSR, or Auto-RP. > Can we add this as well to the document? > Thanks for you comments, > Dino **************** 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 Fri Feb 10 06:59:15 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 1F7Wvi-0004Iz-Vt; Fri, 10 Feb 2006 06:59:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Wvh-0004D8-AM for pim@megatron.ietf.org; Fri, 10 Feb 2006 06:59:13 -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 GAA12916 for ; Fri, 10 Feb 2006 06:57:21 -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 1F7X8Y-00064c-BI for pim@ietf.org; Fri, 10 Feb 2006 07:12:31 -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 k1ABwfhv009247; Fri, 10 Feb 2006 06:58:41 -0500 From: "Jonathan Natale" To: "Tom Pusateri" , Subject: RE: [pim] Working Group Last Call: PIM MIB Date: Fri, 10 Feb 2006 06:58:41 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20060209204357.61C13B842@jj.bangj.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit 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: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org I agree that spare mode is and should be the main and maybe the only focus. my only point is that sparse-dense behavior should maybe have a brief historical/info rfc--does one exist? is there only one vendor that supports it? ...has it gone from the 'recommended' to 'never mind that man behind the curtain' status ???? -$0.02 > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of Tom > Pusateri > Sent: Thursday, February 09, 2006 3:44 PM > To: pim@ietf.org > Subject: Re: [pim] Working Group Last Call: PIM MIB > > > If people want to implement Dense mode, that is their choice. But > as far as the PIM WG is concerned, we have no further interest in > it. That was clear by how hard it was to progress the dense mode > document. No one would even review it. If it wasn't for Jonathan, > the document would have just died. There is maybe a handful of > people in the world who care. > > Those small number of people who have interest in dense mode can > spend their time working on it as private submissions but unless > the feelings of the majority of the PIM working group change > drastically in the future, Dense mode is now outside the scope of > the working group. > > I struggle with any support at all for Dense mode in the MIB. > I suspect it will have to be taken out in order to advance it > to Proposed Standard since the Dense Mode document is an > Experimental Standard. > > We need to be looking forward and not back. We certainly don't > need to write any new documents about things like sparse-dense > mode. Those are implementation choices and the vendors can > document those as they see fit. > > Sorry if this sounds harsh. We just need to move on. > > Thanks, > Tom > > In message <20060209194957.GC30258@nexthop.com> you write: > >John Zwiebel wrote: > >> > >> On Feb 9, 2006, at 9:29 AM, Jonathan Natale wrote: > >> > >> >> > >> >> > >> >>I'm getting the feeling that maybe the working group should publish > >> >>a document (informational?) on sparse-dense. > >> >I agree. > >> > >> Perhaps, but be aware that "sparse-dense" is a cisco specific way of > >> configuring its router, is only there because that was how the > >> transition > >> from pimv1 to pimv2 was supported, and isn't a term used in any IETF > >> document that I'm aware of. > > > > > >Not only Cisco has implemented this. If I'm not mistaken then > >Juniper implements this, I've encountered customer interest in it > >from time to time. > > > > > >> The information document would basically say: > >> > >> If there is no known RP for a multicast group, it is treated as a > >> dense-mode group - by _some_ implementations. > > > >Yeah, it would be fairly short. It might be nice to have some text > >on how a sparse-to-dense or dense-to-sparse transition should be > >handled. > > > > > >Chris > > > >_______________________________________________ > >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 _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Feb 13 19:53: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 1F8oRS-0004x5-9f; Mon, 13 Feb 2006 19:53:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8oRQ-0004ve-4f for pim@megatron.ietf.org; Mon, 13 Feb 2006 19:53: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 TAA06805 for ; Mon, 13 Feb 2006 19:51:30 -0500 (EST) Received: from rrcs-66-91-145-219.west.biz.rr.com ([66.91.145.219] helo=apollo.adtech-inc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8of4-0004Sj-Of for pim@ietf.org; Mon, 13 Feb 2006 20:07:27 -0500 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id <1HT4F39X>; Mon, 13 Feb 2006 14:53:41 -1000 Message-ID: <3D7BA5153B91EB4EBCF4CEDFE6263EA235C3EB@apollo.adtech-inc.com> From: "Singh, Gurpreet" To: pim@ietf.org Date: Mon, 13 Feb 2006 14:53:40 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [pim] PIM-SM: Timing Estimate on new RFC to obsolete RFC 2362 ? 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 see that the latest PIM-SM draft (draft 11) expired in April 2005. I know that some vendor implementations are still based on RFC 2362 and they would like to wait for the new RFC instead of implementing based on the latest draft. Approx when is the draft 11 scheduled for finalizing it into RFC ? Thanks Gurpreet _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Feb 15 10:53: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 1F9OyE-0003KN-JZ; Wed, 15 Feb 2006 10:53:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9OyC-0003K5-F2 for pim@megatron.ietf.org; Wed, 15 Feb 2006 10:53: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 KAA20672 for ; Wed, 15 Feb 2006 10:51:46 -0500 (EST) Received: from exprod8og12.obsmtp.com ([64.18.3.230]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F9PCB-0007gm-02 for pim@ietf.org; Wed, 15 Feb 2006 11:08:03 -0500 Received: from source ([151.190.254.200]) by exprod8ob12.postini.com ([64.18.7.12]) with SMTP; Wed, 15 Feb 2006 07:53:25 PST Received: from fwdefsmtp2.de.ittind.com ([10.32.77.203]) by ittsmtp1 with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 10:54:14 -0500 Received: from njbridge01.avionics.de.ittind.com ([10.37.1.77]) by fwdefsmtp2.de.ittind.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 10:53:24 -0500 Received: from ACDNJMAILSRV03.acd.de.ittind.com ([151.190.1.185]) by njbridge01.avionics.de.ittind.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 10:53:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [pim] Working Group Last Call: PIM MIB Date: Wed, 15 Feb 2006 10:53:22 -0500 Message-ID: Thread-Topic: [pim] Working Group Last Call: PIM MIB thread-index: AcYstYbblmDSqzpYQQOgirGYNCIqUgFkcJ1A From: "Nicholas, Jonathan - ACD " To: "Tom Pusateri" , X-OriginalArrivalTime: 15 Feb 2006 15:53:22.0995 (UTC) FILETIME=[F3245830:01C63247] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable 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: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org All, For the DM Conformance group, the descriptive text should be changed to read, "A collection of objects required for management of PIM Dense Mode (PIM-DM) function. The groups pimSsmGroup and pimSmGroup are also required." Jonathan Nicholas ************************************ This e-mail and any files transmitted with it are proprietary and intende= d solely for the use of the individual or entity to whom they are address= ed. If you have received this e-mail in error please notify the sender. P= lease note that any views or opinions presented in this e-mail are solely= those of the author and do not necessarily represent those of ITT Indust= ries, Inc. The recipient should check this e-mail and any attachments for= the presence of viruses. ITT Industries accepts no liability for any dam= age caused by any virus transmitted by this e-mail. ************************************ =0D _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Wed Feb 15 13:42:58 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 1F9RcA-0002Hj-Q5; Wed, 15 Feb 2006 13:42:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Rc8-0002En-Su for pim@megatron.ietf.org; Wed, 15 Feb 2006 13:42:56 -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 NAA21911 for ; Wed, 15 Feb 2006 13:41:10 -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 1F9RqC-0003iX-HP for pim@ietf.org; Wed, 15 Feb 2006 13:57:29 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 15 Feb 2006 10:42:46 -0800 X-IronPort-AV: i="4.02,118,1139212800"; d="scan'208"; a="405593014:sNHT28647310" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1FIgkQJ013335; Wed, 15 Feb 2006 10:42:46 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 10:42:46 -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); Wed, 15 Feb 2006 10:42:45 -0800 Date: Wed, 15 Feb 2006 10:42:45 -0800 (PST) From: Mike McBride To: "Singh, Gurpreet" Subject: Re: [pim] PIM-SM: Timing Estimate on new RFC to obsolete RFC 2362 ? In-Reply-To: <3D7BA5153B91EB4EBCF4CEDFE6263EA235C3EB@apollo.adtech-inc.com> Message-ID: References: <3D7BA5153B91EB4EBCF4CEDFE6263EA235C3EB@apollo.adtech-inc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 15 Feb 2006 18:42:46.0000 (UTC) FILETIME=[9CC3D700:01C6325F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 The four pim-sm draft authors are meeting to complete the remaining IESG comments. I'm done guessing on when we will actually have a new RFC but, assuming the IESG is satisfied with the draft modifications, we should be near the end. mike On Mon, 13 Feb 2006, Singh, Gurpreet wrote: > Hi > > I see that the latest PIM-SM draft (draft 11) expired in April 2005. I know > that some vendor implementations are still based on RFC 2362 and they would > like to wait for the new RFC instead of implementing based on the latest > draft. Approx when is the draft 11 scheduled for finalizing it into RFC ? > > Thanks > > Gurpreet > > _______________________________________________ > 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 Feb 17 13:16:40 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 1FAA9o-0005O0-Ja; Fri, 17 Feb 2006 13:16:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAA9l-0005Ne-P8 for pim@megatron.ietf.org; Fri, 17 Feb 2006 13:16: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 NAA18516 for ; Fri, 17 Feb 2006 13:14:50 -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 1FAAOE-0000Bj-Fy for pim@ietf.org; Fri, 17 Feb 2006 13:31:35 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2006 10:16:14 -0800 X-IronPort-AV: i="4.02,124,1139212800"; d="scan'208"; a="406657395:sNHT1322521786" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1HIGDWJ010358; Fri, 17 Feb 2006 10:16:14 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 10:16:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Feb 2006 10:16:12 -0800 Message-ID: <6EE7932CC71C8D49A20C0E639BCD21654A8D90@xmb-sjc-21c.amer.cisco.com> Thread-Topic: PIM MIB trap comments Thread-Index: AcYz7jv5lj7XWbEdQtSdS80p/iA3VQ== From: "Andy Kessler $kessler$" To: "David McWalter" X-OriginalArrivalTime: 17 Feb 2006 18:16:13.0820 (UTC) FILETIME=[3C93F3C0:01C633EE] X-Spam-Score: 2.2 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: pim@ietf.org Subject: [pim] PIM MIB trap comments 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 Dave,=20 Some comments on the traps in the PIM MIB draft.=20 1. The way the ciscoPimRPMappingChange defined in the=20 CISCO-PIM-MIB the router actually sends two separate traps for each mapping change - one with the old and one with the new RP mapping. Now this could get kinda crazy when there are hundreds of RP mapping changes and we generate all those traps. I like the approach you took with the pimRPMappingChange.=20 You will only send a trap that 'something has changed' and it can be rate limited.=20 We should consider two things:=20 a. Is there a way we can include information about which RP has changed its mapping information ? Maybe just another object that contains the RP of the last RP mapping change and that gets sent in the trap. This would at least help narrow down figuring out what has changed if you have many RP mappings.=20 b. Should the pimRPMappingChangeCount also increment if a static mapping has changed? Some people may argue that you know when a static mapping changes because you change it. Also it only=20 affects one router. But it is also nice to have a log of when a static mapping has changed especially when you have many=20 people working in operations.=20 2. In the definition of the pimNeighborLoss trap you=20 list the rate limit as pimNeighborLossPeriod. It should be pimNeighborLossTrapPeriod.=20 3. Minor typo: In the pimRPMappingChangeCount definition you have:=20 "Only changes to active mappings cause his count to be=20 incremented." I think you mean "... this count ..." Andy _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Feb 17 13:47:49 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 1FAAdx-0005hm-10; Fri, 17 Feb 2006 13:47:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAdv-0005hc-Jx for pim@megatron.ietf.org; Fri, 17 Feb 2006 13:47:47 -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 NAA21178 for ; Fri, 17 Feb 2006 13:45:59 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAAsL-0001Z0-DB for pim@ietf.org; Fri, 17 Feb 2006 14:02:45 -0500 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 18:47:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 17 Feb 2006 18:47:33 -0000 Message-ID: <52A0FF47062B0B4C80862F2526E024090C203E@enfimail2.datcon.co.uk> Thread-Topic: PIM MIB trap comments Thread-Index: AcYz7jv5lj7XWbEdQtSdS80p/iA3VQAAOn1Q From: "David McWalter" To: "Andy Kessler $kessler$" X-OriginalArrivalTime: 17 Feb 2006 18:47:33.0433 (UTC) FILETIME=[9CEA2290:01C633F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: pim@ietf.org Subject: [pim] RE: PIM MIB trap comments 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 Andy. Thanks for reviewing this - much appreciated. 1.a. The RP address is present in the trap, hidden in the objects pimGroupMappingPimMode and pimGroupMappingPrecedence. These objects drag their OID along with them, including pimGroupMappingRpAddress. So in effect, the trap hands you a whole pimGroupMappingEntry. 1.b. Statically configured RPs are already included. Local static RP configuration may change entries with pimGroupMappingOrigin set to configRp(2), and these can increment pimRPMappingChangeCount like any other mapping change. The description of pimRPMappingChangeCount says that it includes them: ... Such changes may result from configuration of this device, or from automatic RP mapping discovery methods including the PIM Bootstrap Router (BSR) mechanism." I could say 'static configuration of this device,' or 'manual configuration of this device,' if that will make it clearer. Let me know what text you prefer. 2. Thanks - will fix. 3. Thanks - will fix. DMcW. -----Original Message----- From: Andy Kessler (kessler) [mailto:kessler@cisco.com] Sent: 17 February 2006 18:16 To: David McWalter Cc: pim@ietf.org Subject: PIM MIB trap comments Hi Dave,=20 Some comments on the traps in the PIM MIB draft.=20 1. The way the ciscoPimRPMappingChange defined in the=20 CISCO-PIM-MIB the router actually sends two separate traps for each mapping change - one with the old and one with the new RP mapping. Now this could get kinda crazy when there are hundreds of RP mapping changes and we generate all those traps. I like the approach you took with the pimRPMappingChange.=20 You will only send a trap that 'something has changed' and it can be rate limited.=20 We should consider two things:=20 a. Is there a way we can include information about which RP has changed its mapping information ? Maybe just another object that contains the RP of the last RP mapping change and that gets sent in the trap. This would at least help narrow down figuring out what has changed if you have many RP mappings.=20 b. Should the pimRPMappingChangeCount also increment if a static mapping has changed? Some people may argue that you know when a static mapping changes because you change it. Also it only=20 affects one router. But it is also nice to have a log of when a static mapping has changed especially when you have many=20 people working in operations.=20 2. In the definition of the pimNeighborLoss trap you=20 list the rate limit as pimNeighborLossPeriod. It should be pimNeighborLossTrapPeriod.=20 3. Minor typo: In the pimRPMappingChangeCount definition you have:=20 "Only changes to active mappings cause his count to be=20 incremented." I think you mean "... this count ..." Andy _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Feb 17 14:09: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 1FAAyV-0002zL-E4; Fri, 17 Feb 2006 14:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAyT-0002zG-Qt for pim@megatron.ietf.org; Fri, 17 Feb 2006 14:09:01 -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 OAA22625 for ; Fri, 17 Feb 2006 14:07:13 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FABCw-0002Ui-0F for pim@ietf.org; Fri, 17 Feb 2006 14:24:00 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Feb 2006 11:08:51 -0800 X-IronPort-AV: i="4.02,124,1139212800"; d="scan'208"; a="1777381467:sNHT58651556" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1HJ8oQL011628; Fri, 17 Feb 2006 11:08:50 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 11:08:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Feb 2006 11:08:48 -0800 Message-ID: <6EE7932CC71C8D49A20C0E639BCD21654A8DC9@xmb-sjc-21c.amer.cisco.com> Thread-Topic: PIM MIB trap comments Thread-Index: AcYz7jv5lj7XWbEdQtSdS80p/iA3VQAAOn1QAAEXguA= From: "Andy Kessler $kessler$" To: "David McWalter" X-OriginalArrivalTime: 17 Feb 2006 19:08:49.0901 (UTC) FILETIME=[95BFB1D0:01C633F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: pim@ietf.org Subject: [pim] RE: PIM MIB trap comments 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 Comments inline. =20 > -----Original Message----- > From: David McWalter [mailto:DMcW@dataconnection.com]=20 > Sent: Friday, February 17, 2006 10:48 AM > To: Andy Kessler (kessler) > Cc: pim@ietf.org > Subject: RE: PIM MIB trap comments >=20 > Hi Andy. >=20 > Thanks for reviewing this - much appreciated. >=20 > 1.a. The RP address is present in the trap, hidden in the objects > pimGroupMappingPimMode and pimGroupMappingPrecedence. These objects > drag their OID along with them, including=20 > pimGroupMappingRpAddress. So > in effect, the trap hands you a whole pimGroupMappingEntry. >=20 Ok, I thought about that. I suppose its implied that the=20 pimGroupMappingPimMode will apply to the mapping that has caused pimRPMappingChangeCount to increment. There is a lot of implied linkage in the mibs that I don't always follow.=20 > 1.b. Statically configured RPs are already included. Local static RP > configuration may change entries with pimGroupMappingOrigin set to > configRp(2), and these can increment pimRPMappingChangeCount like any > other mapping change. The description of pimRPMappingChangeCount says > that it includes them: > ... > Such changes may result from configuration of this device, > or from automatic RP mapping discovery methods including > the PIM Bootstrap Router (BSR) mechanism." >=20 > I could say 'static configuration of this device,' or 'manual > configuration of this device,' if that will make it clearer. Let me > know what text you prefer. "manual configuration" would be fine. I was fixating on some of the=20 language in the preceding paragraph. I re-read it and if you make the 'manual' change then its clear. Andy _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Feb 23 18:11:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCPcC-00042T-1c; Thu, 23 Feb 2006 18:11:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCPcB-00040V-2T; Thu, 23 Feb 2006 18:11:15 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCPcA-0000X6-Ro; Thu, 23 Feb 2006 18:11:15 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1NNB70e028804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2006 23:11:07 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FCPc3-0006yi-J8; Thu, 23 Feb 2006 18:11:07 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 23 Feb 2006 18:11:07 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Internet Architecture Board , pim chair , pim mailing list , RFC Editor Subject: [pim] Protocol Action: 'Anycast-RP using PIM' to Proposed Standard X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: