Vero Zheng | 8 Jun 2012 03:59
Favicon

Trail Dry Run (for RFC4601 deployment and implementation survey) - Please participate. Thanks!

Dear WG,

 

This email start a trail dry run for the RFC4601 deployment and implementation survey in this mailing list.

This dry run will last for one week, please participate. This will help us to make sure the survey functions before we start to send it to wider audience.

 

Marshall Eubanks has agreed to anonymize the response to this Questionnaire. Please send your Questionnaire responses to his email address, marshall.eubanks <at> gmail.com.

Marshall requests that such responses include the string "RFC 4601 bis Questionnaire" in the subject field.

 

The Questionnaire is attached in blue.

 

Thanks for your participation and help in advance.

 

BR,

Rishabh, Jeffrey & Vero

 

Questionnaire

 

Introduction:

 

PIM-SM was first published as RFC 2117 in 1997 and then again as

RFC 2362 in 1998.  The protocol was classified as Experimental in

both of these documents.  The PIM-SM protocol specification was

then rewritten in whole and advanced to Proposed Standard as

RFC 4601 in 2006. Considering the multiple independent

implementations developed and the successful operational

experience gained, the IETF has decided to advance the PIM-SM

routing protocol to Draft Standard.  This survey intends to

provide supporting documentation to advance the Protocol

Independent Multicast - Sparse Mode (PIM-SM) routing protocol

from IETF Proposed Standard to Draft Standard. (Due to RFC 6410,

now the intention is to progress it to Internet Standard.  Draft Standard

is not used anymore.)

 

This survey is issued on behalf of the IETF PIM Working Group.

 

The responses will be collected by neutral third-party and kept

strictly confidential; only the final combined results will be

published.  Marshall Eubanks has agreed to anonymize the response

to this Questionnaire.  Marshall has a long experience with

Multicast but has no direct financial interest in this matter,

nor ties to any of the vendors involved.  He is also a member of

the IAOC, Chair of the IETF Trust and co-chair of the IETF

Layer 3 VPN Working Group.  Please send Questionnaire responses

to his email address, marshall.eubanks <at> gmail.com.  He requests

that such responses include the string "RFC 4601 bis Questionnaire"

in the subject field.

 

Questions for operators:

 

1       Have you deployed PIM-SM in your network?

 

2       How long have you had PIM-SM deployed in your network?

        Do you know if your deployment is based on the most recent

        RFC4601?

 

3       Have you deployed PIM-SM for IPv6 in your network?

 

4       Are you using equipment with different (multi-vendor) PIM-SM

        implementations for your deployment?

 

5       Have you encountered any inter-operability or backward-

        compatibility issues amongst differing implementations?

        If yes, what are your concerns about these issues?

 

6       Have you deployed both dense mode and sparse mode in your

        network?

 

        If yes, do you route between these modes using features such

        as *,*,RP or PMBR?

 

7       To what extent have you deployed PIM functionality, like BSR,

        SSM, and Explicit Tracking?

 

8       Which RP mapping mechanism do you use: Static, AutoRP, or BSR?

 

9       How many RPs have you deployed in your network?

 

10      If you use Anycast-RP, is it Anycast-RP using MSDP (RFC 3446)

        or Anycast-RP using PIM (RFC 4610)?

 

11      Do you have any other comments on PIM-SM deployment in your

        network?

 

Questions for implementers:

 

1       Have you implemented PIM-SM?

 

2       Is the PIM-SM implementation based on RFC 2632 or RFC 4601?

 

3       Have you implemented (*,*, RP) state of RFC 4601? What is the

        rationale behind implementing or omitting (*,*,RP)?

 

4       Have you implemented the PMBR as specified in RFC 4601 and

        RFC 2715?

        What is the rationale behind implementing or omitting PMBR?

 

5       Have you implemented other features and functions of RFC 4601:

                - SSM

                - Join Suppression

                - Explicit tracking

                - Register mechanism

                - SPT switchover at last-hop router

                - Assert mechanism

                - Hashing of group to RP mappings

 

6       Does your PIM-SM implementation support IPv6?

 

7       Have you encountered any inter-operability issues with other

        PIM implementations in trials or in the field?

 

8       Do you have any other comments or concerns about PIM-SM as

        specified in RFC4601?

_______________________________________________
pim mailing list
pim <at> ietf.org
https://www.ietf.org/mailman/listinfo/pim
Debojyoti Roy | 22 Jun 2012 08:27
Picon

Help regarding secondary address list and SPTbit

Hi friends,
I have got some querry related with secondary address and SPTbit in PIM-SM:-

1. Suppose a hello packet has been sent from r1 to r100 where r2, r3, r4 are in the secondary address list. Now, if a (*,G) Join/Prune message has been sent from r3 then what will happen ? Will that Join/Prune packet be forwarded towards RP ?

---------------------------------------

2. Suppose a R1 is a router and i1, i2, i3 are three interfaces of that router. Now, i1, i2, i3 are connected with 1.1.1.0, 2.2.2.0 and 3.3.3.0 network. After hello packet exchange, from 3.3.3.X a (*,G) Join has been sent. Obviously that is forwarded to the RP(say RP is connected with 1.1.1.0 network). Then a (S,G) Join has been sent to R1 from 3.3.3.Y where S is 2.2.2.A. So, R1 naturally send that packet to i2.

Now in this situation is SPTbit(S,G) set where S is 2.2.2.A ?

If not please tell me when SPTbit(S,G) will be set ?

---------------------------------------

Thanks,
Debojyoti Roy
_______________________________________________
pim mailing list
pim <at> ietf.org
https://www.ietf.org/mailman/listinfo/pim
Stig Venaas | 22 Jun 2012 22:20

PIM survey for operators

The IETF pim working group is conducting a survey in order to advance
the PIM Sparse Mode spec on the IETF Standards Track, and would like
input from operators. The survey ends July 20th. Please see below for
more information.

thank you,
pim chairs Mike & Stig

Introduction:

PIM-SM was first published as RFC 2117 in 1997 and then again as
RFC 2362 in 1998.  The protocol was classified as Experimental in
both of these documents.  The PIM-SM protocol specification was
then rewritten in whole and advanced to Proposed Standard as
RFC 4601 in 2006. Considering the multiple independent
implementations developed and the successful operational
experience gained, the IETF has decided to advance the PIM-SM
routing protocol to Draft Standard.  This survey intends to
provide supporting documentation to advance the Protocol
Independent Multicast - Sparse Mode (PIM-SM) routing protocol
from IETF Proposed Standard to Draft Standard. (Due to RFC 6410,
now the intention is to progress it to Internet Standard.  Draft Standard
is no longer used.)

This survey is issued on behalf of the IETF PIM Working Group.

The responses will be collected by a neutral third-party and kept
strictly confidential; only the final combined results will be
published.  Marshall Eubanks has agreed to anonymize the response
to this Questionnaire.  Marshall has a long experience with
Multicast but has no direct financial interest in this matter,
nor ties to any of the vendors involved.  He is also a member of
the IAOC, Chair of the IETF Trust and co-chair of the IETF
Layer 3 VPN Working Group.  Please send Questionnaire responses
to his email address, marshall.eubanks <at> gmail.com.  He requests
that such responses include the string "RFC 4601 bis Questionnaire" in
the subject field.

Before answering the questions, please comple the following background
information.

Name of the Respondent:
Affliation/Organization:
Contact Email:
Provide description of PIM deployment:
Do you wish to keep the information provided confidential:

Questions:

1       Have you deployed PIM-SM in your network?

2       How long have you had PIM-SM deployed in your network?
        Do you know if your deployment is based on the most recent
        RFC4601?

3       Have you deployed PIM-SM for IPv6 in your network?

4       Are you using equipment with different (multi-vendor) PIM-SM
        implementations for your deployment?

5       Have you encountered any inter-operability or backward-
        compatibility issues amongst differing implementations?
        If yes, what are your concerns about these issues?

6       Have you deployed both dense mode and sparse mode in your
        network?

        If yes, do you route between these modes using features such
        as *,*,RP or PMBR?

7       To what extent have you deployed PIM functionality, like BSR,
        SSM, and Explicit Tracking?

8       Which RP mapping mechanism do you use: Static, AutoRP, or BSR?

9       How many RPs have you deployed in your network?

10      If you use Anycast-RP, is it Anycast-RP using MSDP (RFC 3446)
        or Anycast-RP using PIM (RFC 4610)?

11      Do you have any other comments on PIM-SM deployment in your
        network?
Stig Venaas | 22 Jun 2012 22:28

PIM survey for implementors

The IETF pim working group is conducting a survey in order to advance
the PIM Sparse Mode spec on the IETF Standards Track, and would like
input from implementors. The survey ends July 20th. Please see below
for more information.

thank you,
pim chairs Mike & Stig

Introduction:

PIM-SM was first published as RFC 2117 in 1997 and then again as RFC
2362 in 1998.  The protocol was classified as Experimental in both of
these documents.  The PIM-SM protocol specification was then rewritten
in whole and advanced to Proposed Standard as RFC 4601 in 2006.
Considering the multiple independent implementations developed and the
successful operational experience gained, the IETF has decided to
advance the PIM-SM routing protocol to Draft Standard.  This survey
intends to provide supporting documentation to advance the Protocol
Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF
Proposed Standard to Draft Standard. (Due to RFC 6410, now the
intention is to progress it to Internet Standard.  Draft Standard is
not used anymore.)

This survey is issued on behalf of the IETF PIM Working Group.

The responses will be collected by neutral third-party and kept
strictly confidential; only the final combined results will be
published.  Marshall Eubanks has agreed to anonymize the response to
this Questionnaire.  Marshall has a long experience with Multicast but
has no direct financial interest in this matter, nor ties to any of the
vendors involved.  He is also a member of the IAOC, Chair of the IETF
Trust and co-chair of the IETF Layer 3 VPN Working Group.  Please send
Questionnaire responses to his email address,
marshall.eubanks <at> gmail.com.  He requests that such responses include
the string "RFC 4601 bis Questionnaire" in the subject field.

Before answer the questions, please fill the following background 
information.

Name of the Respondent:
Affliation/Organization:
Contact Email:
Provide description of PIM implementation:
Do you wish to keep the information provided confidential:

Questions:

1       Have you implemented PIM-SM?

2       Is the PIM-SM implementation based on RFC 2632 or RFC 4601?

3       Have you implemented (*,*, RP) state of RFC 4601? What is the
         rationale behind implementing or omitting (*,*,RP)?

4       Have you implemented the PMBR as specified in RFC 4601 and
         RFC 2715?
         What is the rationale behind implementing or omitting PMBR?

5       Have you implemented other features and functions of RFC 4601:
                 - SSM
                 - Join Suppression
                 - Explicit tracking
                 - Register mechanism
                 - SPT switchover at last-hop router
                 - Assert mechanism
                 - Hashing of group to RP mappings

6       Does your PIM-SM implementation support IPv6?

7       Have you encountered any inter-operability issues with other
         PIM implementations in trials or in the field?

8       Do you have any other comments or concerns about PIM-SM as
         specified in RFC4601?
Bruce, Paul | 28 Jun 2012 08:56
Picon

FW: [uknof] FW: PIM survey for operators

Dear PIM Chairs,

I have received this email thread through the UKNOF mailing list. I have
subscribed to the PIM mailing list for future reference.

I am happy to complete the survey if every little helps. But could I
request that you re-send the original email to
paul.bruce <at> virginmedia.co.uk

Regards,

Paul

Paul Bruce

Data Architecture
Virgin Media
Media House, Bartley Wood Business Park, Hook RG27 9UP

M +44(0)7785 515 617
D +44(0)1256 75 3631
E paul.bruce <at> virginmedia.co.uk

-----Original Message-----
From: Adrian Farrel [mailto:adrian <at> olddog.co.uk] 
Sent: 27 June 2012 22:11
To: Bruce, Paul
Subject: RE: [uknof] FW: PIM survey for operators

Hi again, Paul (and sorry for the silly mistyping of your name which,
although it must happen all the time, can be nothing but annoying).

The original request is in the PIM archive at
http://www.ietf.org/mail-archive/web/pim/current/msg02448.html

If you need a specific email in your in-box, I suggest mailing to
pim <at> ietf.org and asking whether they would mind re-sending the survey
request. 

If you have any questions about the survey then pim <at> ietf.org is the
right place to send them.

I suggest sending your survey response direct to
marshall.eubanks <at> gmail.com as described in the survey header. Marshall
is collating the responses and annonymising for anyone who wants stuff
kept private.

Cheers,
Adrian

> -----Original Message-----
> From: Bruce, Paul [mailto:Paul.Bruce <at> virginmedia.co.uk]
> Sent: 27 June 2012 08:25
> To: adrian <at> olddog.co.uk
> Subject: RE: [uknof] FW: PIM survey for operators
> 
> Adrian,
> 
> I have just subscribed to the PIM list, do you have another email to 
> back up the email below or do I just reply to pim <at> ietf.org
> 
> Paul
> 
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian <at> olddog.co.uk]
> Sent: 26 June 2012 21:54
> To: Bruce, Paul
> Subject: RE: [uknof] FW: PIM survey for operators
> 
> Hi Bruce,
> 
> The PIM mailing list can't mail you. If you are subscribed that list 
> you would have seen a copy.
> 
> Would it be enough to see an email from the PIM working group
co-chairs?
> 
> Cheers,
> Adrian
> 
> > -----Original Message-----
> > From: Bruce, Paul [mailto:Paul.Bruce <at> virginmedia.co.uk]
> > Sent: 26 June 2012 10:21
> > To: adrian <at> olddog.co.uk
> > Subject: RE: [uknof] FW: PIM survey for operators
> >
> > Adrian,
> >
> > I am happy to respond to the PIM survey, but would like to receive 
> > an email direct from pim <at> ietf.org can you ping whomever
> >
> > Paul
> >
> > Paul Bruce
> >
> > Data Architecture
> > Virgin Media
> > Media House, Bartley Wood Business Park, Hook RG27 9UP
> >
> >
> > M +44(0)7785 515 617
> > D +44(0)1256 75 3631
> > E paul.bruce <at> virginmedia.co.uk
> >
> >
> >
> > -----Original Message-----
> > From: uknof-bounces <at> lists.uknof.org.uk 
> > [mailto:uknof-bounces <at> lists.uknof.org.uk] On Behalf Of Adrian Farrel
> > Sent: 26 June 2012 09:09
> > To: uknof <at> lists.uknof.org.uk
> > Subject: [uknof] FW: PIM survey for operators
> >
> > Hi UKnoffers,
> >
> > In case this doesn't reach you by other means, the IETF PIM 
> > community is seeking input on PIM deployments. Your responses can be

> > anonymised as described in the covering email.
> >
> > Thanks for any help.
> >
> > Adrian
> >
> > > -----Original Message-----
> > > From: pim-bounces <at> ietf.org [mailto:pim-bounces <at> ietf.org] On Behalf

> > > Of Stig Venaas
> > > Sent: 22 June 2012 21:21
> > > To: pim <at> ietf.org
> > > Subject: [pim] PIM survey for operators
> > >
> > > The IETF pim working group is conducting a survey in order to 
> > > advance the PIM Sparse Mode spec on the IETF Standards Track, and 
> > > would like input from operators. The survey ends July 20th. Please

> > > see below for more information.
> > >
> > > thank you,
> > > pim chairs Mike & Stig
> > >
> > >
> > > Introduction:
> > >
> > > PIM-SM was first published as RFC 2117 in 1997 and then again as 
> > > RFC
> > > 2362 in 1998.  The protocol was classified as Experimental in both

> > > of these documents.  The PIM-SM protocol specification was then 
> > > rewritten
> >
> > > in whole and advanced to Proposed Standard as RFC 4601 in 2006.
> > > Considering the multiple independent implementations developed and

> > > the
> >
> > > successful operational experience gained, the IETF has decided to 
> > > advance the PIM-SM routing protocol to Draft Standard.  This 
> > > survey intends to provide supporting documentation to advance the 
> > > Protocol Independent Multicast - Sparse Mode (PIM-SM) routing 
> > > protocol from IETF Proposed Standard to Draft Standard. (Due to 
> > > RFC 6410, now the intention is to progress it to Internet 
> > > Standard.  Draft Standard is
> 
> > > no longer used.)
> > >
> > > This survey is issued on behalf of the IETF PIM Working Group.
> > >
> > > The responses will be collected by a neutral third-party and kept 
> > > strictly confidential; only the final combined results will be 
> > > published.  Marshall Eubanks has agreed to anonymize the response 
> > > to
> 
> > > this Questionnaire.  Marshall has a long experience with Multicast

> > > but
> >
> > > has no direct financial interest in this matter, nor ties to any 
> > > of the vendors involved.  He is also a member of the IAOC, Chair 
> > > of the
> 
> > > IETF Trust and co-chair of the IETF Layer 3 VPN Working Group.
> > > Please
> >
> > > send Questionnaire responses to his email address, 
> > > marshall.eubanks <at> gmail.com.  He requests that such responses 
> > > include
> 
> > > the string "RFC 4601 bis Questionnaire" in the subject field.
> > >
> > > Before answering the questions, please comple the following 
> > > background
> >
> > > information.
> > >
> > > Name of the Respondent:
> > > Affliation/Organization:
> > > Contact Email:
> > > Provide description of PIM deployment:
> > > Do you wish to keep the information provided confidential:
> > >
> > > Questions:
> > >
> > > 1       Have you deployed PIM-SM in your network?
> > >
> > > 2       How long have you had PIM-SM deployed in your network?
> > >         Do you know if your deployment is based on the most recent
> > >         RFC4601?
> > >
> > > 3       Have you deployed PIM-SM for IPv6 in your network?
> > >
> > > 4       Are you using equipment with different (multi-vendor)
PIM-SM
> > >         implementations for your deployment?
> > >
> > > 5       Have you encountered any inter-operability or backward-
> > >         compatibility issues amongst differing implementations?
> > >         If yes, what are your concerns about these issues?
> > >
> > > 6       Have you deployed both dense mode and sparse mode in your
> > >         network?
> > >
> > >         If yes, do you route between these modes using features
such
> > >         as *,*,RP or PMBR?
> > >
> > > 7       To what extent have you deployed PIM functionality, like
> BSR,
> > >         SSM, and Explicit Tracking?
> > >
> > > 8       Which RP mapping mechanism do you use: Static, AutoRP, or
> BSR?
> > >
> > > 9       How many RPs have you deployed in your network?
> > >
> > > 10      If you use Anycast-RP, is it Anycast-RP using MSDP (RFC
> 3446)
> > >         or Anycast-RP using PIM (RFC 4610)?
> > >
> > > 11      Do you have any other comments on PIM-SM deployment in
your
> > >         network?
> > > _______________________________________________
> > > pim mailing list
> > > pim <at> ietf.org
> > > https://www.ietf.org/mailman/listinfo/pim
> >
> >
> >
> >
> > --------------------------------------------------------------------
> > Save Paper - Do you really need to print this e-mail?
> >
> > Visit www.virginmedia.com for more information, and more fun.
> >
> > This email and any attachments are or may be confidential and 
> > legally
> privileged
> > and are sent solely for the attention of the addressee(s). If you 
> > have
> received
> > this
> > email in error, please delete it from your system: its use, 
> > disclosure
> 
> > or
> copying is
> > unauthorised. Statements and opinions expressed in this email may 
> > not represent those of Virgin Media. Any representations or 
> > commitments in
> 
> > this email are subject to contract.
> >
> > Registered office: Media House, Bartley Wood Business Park, Hook, 
> > Hampshire,
> > RG27 9UP
> > Registered in England and Wales with number 2591237
> 
> 
> --------------------------------------------------------------------
> Save Paper - Do you really need to print this e-mail?
> 
> Visit www.virginmedia.com for more information, and more fun.
> 
> This email and any attachments are or may be confidential and legally
privileged
> and are sent solely for the attention of the addressee(s). If you have
received
> this
> email in error, please delete it from your system: its use, disclosure

> or
copying is
> unauthorised. Statements and opinions expressed in this email may not 
> represent those of Virgin Media. Any representations or commitments in

> this email are subject to contract.
> 
> Registered office: Media House, Bartley Wood Business Park, Hook, 
> Hampshire,
> RG27 9UP
> Registered in England and Wales with number 2591237

--------------------------------------------------------------------
Save Paper - Do you really need to print this e-mail?

Visit www.virginmedia.com for more information, and more fun.

This email and any attachments are or may be confidential and legally privileged
and are sent solely for the attention of the addressee(s). If you have received this
email in error, please delete it from your system: its use, disclosure or copying is
unauthorised. Statements and opinions expressed in this email may not represent
those of Virgin Media. Any representations or commitments in this email are
subject to contract. 

Registered office: Media House, Bartley Wood Business Park, Hook, Hampshire, RG27 9UP
Registered in England and Wales with number 2591237
internet-drafts | 28 Jun 2012 23:05
Picon
Favicon

I-D Action: draft-ietf-pim-ecmp-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Protocol Independent Multicast Working Group of the IETF.

	Title           : Protocol Independent Multicast ECMP Redirect
	Author(s)       : Yiqun Cai
                          Liming Wei
                          Heidi Ou
                          Vishal Arya
                          Sunil Jethwani
	Filename        : draft-ietf-pim-ecmp-04.txt
	Pages           : 12
	Date            : 2012-06-28

Abstract:
   A Protocol Independent Multicast (PIM) router uses the Reverse Path
   Forwarding (RPF) procedure to select an upstream interface and router
   to build forwarding state.  When there are equal cost multiple paths
   (ECMP), existing implementations often use hash algorithms to select
   a path.  Such algorithms do not allow the spread of traffic among the
   ECMPs according to administrative metrics.  This usually leads to
   inefficient or ineffective use of network resources.  This document
   introduces the ECMP Redirect, a mechanism to improve the RPF
   procedure over ECMPs.  It allows ECMP path selection to be based on
   administratively selected metrics, such as data transmission delays,
   path preferences and routing metrics.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pim-ecmp

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pim-ecmp-04

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pim-ecmp-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
RFC Errata System | 28 Jun 2012 22:29
Favicon

[Editorial Errata Reported] RFC3973 (3270)


The following errata report has been submitted for RFC3973,
"Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3973&eid=3270

--------------------------------------
Type: Editorial
Reported by: Joseph Weinstein <weinstein <at> bbn.com>

Section: 4.5.1

Original Text
-------------
if StateRefreshCapable(I) == TRUE
         set PT(S,G) to largest active holdtime read from a Prune
         message accepted on I;

Corrected Text
--------------
if StateRefreshCapable(I) == TRUE
         set PT(S,G,I) to largest active holdtime read from a Prune
         message accepted on I;

Notes
-----
No macro PT(S,G) is defined anywhere in the RFC; the reference appears to be to P(S,G,I).

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3973 ( draft-ietf-pim-dm-new-v2-05)
--------------------------------------
Title               : Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)
Publication Date    : January 2005
Author(s)           : A. Adams, J. Nicholas, W. Siadak
Category            : EXPERIMENTAL
Source              : protocol independent multicast
Area                : Routing
Stream              : IETF
Verifying Party     : IESG
RFC Errata System | 28 Jun 2012 22:43
Favicon

[Technical Errata Reported] RFC3973 (3271)


The following errata report has been submitted for RFC3973,
"Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3973&eid=3271

--------------------------------------
Type: Technical
Reported by: Joseph Weinstein <weinstein <at> bbn.com>

Section: 4.5.1

Original Text
-------------
if StateRefreshCapable(I) == TRUE
         set PT(S,G) to largest active holdtime read from a Prune
         message accepted on I;

Corrected Text
--------------
if StateRefreshCapable(I) == TRUE
         set PT(S,G) to the Holdtime from an active Prune received on
         interface I. The Holdtime used SHOULD be the largest active one
         but MAY be the most recently received active Prune Holdtime.

Notes
-----
It is not clear what is meant by the "largest active holdtime", and in any event sec. 4.4.2.3 specifies a
slightly different rule:

     Send State Refresh(S,G) out interface I
       The router has refreshed the Prune(S,G) state on interface I.
       The router MUST reset the Prune Timer (PT(S,G,I)) to the Holdtime
       from an active Prune received on interface I.  The Holdtime used
       SHOULD be the largest active one but MAY be the most recently
       received active Prune Holdtime.

The concept of an "active Prune" is not defined in this RFC. Perhaps the intent is that an "active Prune" is
any prune received since the interface last entered the Pruned state?

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3973 ( draft-ietf-pim-dm-new-v2-05)
--------------------------------------
Title               : Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)
Publication Date    : January 2005
Author(s)           : A. Adams, J. Nicholas, W. Siadak
Category            : EXPERIMENTAL
Source              : protocol independent multicast
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

Gmane