Skip to main content

PIM Group-to-Rendezvous-Point Mapping
draft-ietf-pim-group-rp-mapping-10

Revision differences

Document history

Date Rev. By Action
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Peter Saint-Andre
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
10 (System) post-migration administrative database adjustment to the Yes position for Dan Romascanu
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Ronald Bonica
2011-02-08
10 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-02-07
10 (System) IANA Action state changed to No IC from In Progress
2011-02-07
10 (System) IANA Action state changed to In Progress
2011-02-07
10 Amy Vezza IESG state changed to Approved-announcement sent
2011-02-07
10 Amy Vezza IESG has approved the document
2011-02-07
10 Amy Vezza Closed "Approve" ballot
2011-02-07
10 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2011-02-07
10 Adrian Farrel Approval announcement text changed
2011-02-07
10 Adrian Farrel Approval announcement text regenerated
2011-02-07
10 Adrian Farrel Ballot writeup text changed
2011-02-04
10 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss
2011-02-01
10 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to Yes from Discuss
2011-01-27
10 (System) New version available: draft-ietf-pim-group-rp-mapping-10.txt
2011-01-24
10 Peter Saint-Andre [Ballot Position Update] Position for Peter Saint-Andre has been changed to No Objection from Discuss
2011-01-14
10 David Harrington Closed request for Last Call review by TSVDIR with state 'No Response'
2011-01-12
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-01-12
09 (System) New version available: draft-ietf-pim-group-rp-mapping-09.txt
2011-01-07
10 (System) Removed from agenda for telechat - 2011-01-06
2011-01-06
10 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2011-01-06
10 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-01-05
10 Ron Bonica [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Discuss
2011-01-05
10 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-01-05
10 Peter Saint-Andre
[Ballot discuss]
This is a fine document. However, the algorithm does not specify rules for determining which hash value or IP address is "highest", which …
[Ballot discuss]
This is a fine document. However, the algorithm does not specify rules for determining which hash value or IP address is "highest", which might inhibit interoperability. Please specify such rules (e.g., convert to "network byte order" octet string representation and then apply i;octet collation from RFC 4790), or refer to specifications that define such rules.
2011-01-05
10 Peter Saint-Andre [Ballot Position Update] New position, Discuss, has been recorded
2011-01-05
10 Tim Polk
[Ballot discuss]
This is a pretty straightforward discuss, and should be easy to clear.  As noted in Vincent Roca's security
directorate review, the document would …
[Ballot discuss]
This is a pretty straightforward discuss, and should be easy to clear.  As noted in Vincent Roca's security
directorate review, the document would benefit from some expansion of the security considerations.  In particular,
some pointers to mechanisms for learning group-to-rp mappings that satisfy the constraint are considered secure
would be helpful.  Please use Vincent's review as an input to your revisions.
2011-01-05
10 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded
2011-01-04
10 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Vincent Roca.
2011-01-04
10 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-01-04
10 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-01-04
10 Dan Romascanu
[Ballot comment]
1. Section 5:

  A network management station can determine the RP for a specific
  group in a specific router by running …
[Ballot comment]
1. Section 5:

  A network management station can determine the RP for a specific
  group in a specific router by running this algorithm on the
  Group-to-RP mapping table fetched using SNMP MIB objects.

MIB objects are meant to work not only with SNMP. Please change 'SNMP MIB objects' to 'SMI MIB objects' or just 'MIB objects'.

2. Need to expand MIB and SNMP at first occurence.
2011-01-04
10 Dan Romascanu
[Ballot discuss]
The issue of the relation between this document and RFC 5060 was raised by Adrian with the MIB Doctors. At the end of …
[Ballot discuss]
The issue of the relation between this document and RFC 5060 was raised by Adrian with the MIB Doctors. At the end of the discussion which prompted to various methods of altering the behavior of the routers that already support the MIB module the resolution communicated by Adrian was: 'we have decided that we do NOT want to update the semantics of the existing objects'.

I am still to be convinced that this is the case.

7.  Interpretation of MIB Objects

  The algorithm defined in this document does not use the concept of
  precedence and therefore the values configured in the
  'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects of
  the 'pimGroupMappingTable' table in the PIM-STD-MIB module [RFC5060]
  are not applicable to the new algorithm.  The objects still retain
  their meaning for 'legacy' implementations, but since the algorithm
  defined in this document is to be used in preference to that found in
  PIM-SM [RFC4601] and PIM-STD-MIB [RFC5060], the usage of these fields
  will decline as implementations are upgraded to support the new
  algorithm.

First, in RFC 5060 the  'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects are in two different tables - pimGroupMappingTable and pimStaticRPTable. Each of the table has a different 'precedence' object and a different behavior.

Does pimStaticRPTable has any function with the new RP mapping algorithm? In RFC 5060 it is used to define static entries that may precede and override those defined by the algorithm in 5060. Does this apply also to the algorithm defined here?

What does exactly mean 'the usage of these fields will decline'? All the MIB module defined in RFC 5060 is supported ('we do not want to update the semantics') - so what happens with the pimGroupMappingTable? Section 8 describes how objects in this table will continue to be used to indicate Group-to-RP mapping.  Whay I am missing is what happenss if a manager creates a new entry as per RFC 5060? Should the router just ignore it? We cannot assume all managers are 'well-bahaved' and we need to prevent I think mis-configuration.

If the writeable part of the of this table is not disabled, this would be a serious security problem, as it would interfere with the works of the new algorithm. 

A proper solution should include an update of RFC 5060, including changes in MODULE-COMPLIANCE and possibly a new read-only table that would help the operators read the entries created as result of the application of the new mechanism. I understand that the authors and WG do not plan to do this in the near future, but they need to define a clear and acceptable behavior of the agents runing RFC 5060. Dully obsoleting RFC 5060 (and the usage of the MIB module defined there) would be another solution at this point, but this is not what the WG wants, as I understand.
2011-01-04
10 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded
2011-01-03
10 Ron Bonica
[Ballot discuss]
This document is well-written, and I have no issue with it, per se.

However, the document that it updates, RFC 4601, has …
[Ballot discuss]
This document is well-written, and I have no issue with it, per se.

However, the document that it updates, RFC 4601, has 91 errata in the hold-state, 1 errata in the verified state, and two errata in the reported state. I fear that updating RFC 4601 will only make that base document less useable.

Please consider reworking RFC 4601, replacing section 4.7.1 with the algorithm described in the current document. As you do that, you might also want to fix as many errata as possible.
2011-01-03
10 Ron Bonica [Ballot Position Update] New position, Discuss, has been recorded
2011-01-02
10 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-01-02
10 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded
2010-12-31
10 Adrian Farrel State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup.
2010-12-31
10 Adrian Farrel
[Ballot comment]
Routing Area Directorate review by Dimitri Papadimitriou raises a few very minor editorial points that should be looked at together with any other …
[Ballot comment]
Routing Area Directorate review by Dimitri Papadimitriou raises a few very minor editorial points that should be looked at together with any other comments and issues raised during IESG review.

> Section 1:
>
> - "Each PIM-SM router may learn Group-to-RP mappings through
>    various mechanisms." which mechanisms ? ref's would be helpful
>
> - "It is critical that each router select the same 'RP' for a specific
>    multicast group address." why ? a short sentence would be helpful
>    - note this requirement applies to al routers in the same "domain"
>
> Section 4:
>
> - "A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to
>    an entry learned for PIM-SM mode."
>    is this reason dictated by arbitrary criteria or protocol operation
>    criteria (dictated by RFC 5059) or other ?
>
> Section 5:
>
> - Add ref's to BSR and Auto-RP in sentence
>  "In this case, to support some specific applications, they might like to
>    learn Group-to-RP mappings dynamically using either BSR or Auto-RP
>    mechanism."
>
> - "This is not an issue for IPv6 Multicast address ranges." what "this"
>    refers to ?
>
> Section 6:
>
> - What's the input to this algorithm ? there is a need to describe the set
>  of information onto which this procedure applies (the output is implicit).
>
> - The description seems to mandate a sequential execution (from 1 to
>    10) but this is not stated ahead in the Section 6.
>
> Section 9:
>
> - " The algorithm in this document MUST be used. " on all routers in
>  the domain? Please clarify.
>
> - "improve stability under misconfiguration" stability of what ?
>
> Section 11:
>
> - does the term "block" refers to disable or filter ? or left unspecified ?
2010-12-31
10 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2010-12-31
10 Adrian Farrel Ballot has been issued
2010-12-31
10 Adrian Farrel Created "Approve" ballot
2010-12-28
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-12-28
08 (System) New version available: draft-ietf-pim-group-rp-mapping-08.txt
2010-12-24
10 Adrian Farrel State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead.
2010-12-23
10 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2010-12-17
10 David Harrington Request for Last Call review by TSVDIR is assigned to Marshall Eubanks
2010-12-17
10 David Harrington Request for Last Call review by TSVDIR is assigned to Marshall Eubanks
2010-12-16
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Vincent Roca
2010-12-16
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Vincent Roca
2010-12-15
10 Amanda Baber We understand that this document does not require any IANA actions.
2010-12-10
10 Adrian Farrel Placed on agenda for telechat - 2011-01-06
2010-12-09
10 Amy Vezza Last call sent
2010-12-09
10 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (PIM Group-to-RP Mapping) to Proposed Standard


The IESG has received a request from the Protocol Independent Multicast
WG (pim) to consider the following document:
- 'PIM Group-to-RP Mapping'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-12-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pim-group-rp-mapping/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pim-group-rp-mapping/
2010-12-09
10 Adrian Farrel Last Call was requested
2010-12-09
10 Adrian Farrel State changed to Last Call Requested from AD Evaluation::AD Followup.
2010-12-09
10 Adrian Farrel Last Call text changed
2010-12-09
10 (System) Ballot writeup text was added
2010-12-09
10 (System) Last call text was added
2010-12-09
10 (System) Ballot approval text was added
2010-12-09
10 Adrian Farrel Ballot writeup text changed
2010-12-09
10 Adrian Farrel Ballot writeup text changed
2010-12-09
10 Adrian Farrel Ballot writeup text changed
2010-12-08
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-12-08
07 (System) New version available: draft-ietf-pim-group-rp-mapping-07.txt
2010-12-08
10 Adrian Farrel State changed to AD Evaluation::Revised ID Needed from AD Evaluation::External Party.
2010-12-06
10 Adrian Farrel
State changed to AD Evaluation::External Party from AD Evaluation::AD Followup.
Question sent to MIB experts

---

Dear MIB doctors,

Help!

The multicast routing protocol, PIM-SM …
State changed to AD Evaluation::External Party from AD Evaluation::AD Followup.
Question sent to MIB experts

---

Dear MIB doctors,

Help!

The multicast routing protocol, PIM-SM (RFC 4601), has an algorithm to choose a rendezvous point from information learned by the protocol. This algorithm has been updated to be more sophisticated in draft-ietf-pim-group-rp-mapping (which updates RFC 4601).

PIM-STD-MIB in RFC 5060 defines objects for use in the RFC 4601 algorithm (pimGroupMappingPrecedence and pimStaticRPPrecedence). These objects are no longer required once the algorithm in draft-ietf-pim-group-rp-mapping is implemented.

The question is about deprecation of these objects.

Note that RFC 4601 implementations will continue to exist.

Options appear to be:

1. Issue an update to RFC 5060 in step with draft-ietf-pim-group-rp-mapping.
The update would deprecate the two objects.
It is my understanding that "updates" to MIB modules are not preferred. It is seen as better to "obsolete" with a new module version number.

2.. Issue an update to RFC 5060 in step with draft-ietf-pim-group-rp-mapping.
The update would add text to the description clauses of the two objects.

3. Issue an Erratum for RFC 5060 with text that notes the change in usage for the two objects.

4. Include text in draft-ietf-pim-group-rp-mapping to explain the changed use for the two objects.
This is the approach currently employed by the authors (although they use the word "deprecate" which may be too strong).

Any help gratefully received.
Thanks,
Adrian
2010-12-05
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-12-05
06 (System) New version available: draft-ietf-pim-group-rp-mapping-06.txt
2010-09-23
10 Adrian Farrel State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Adrian Farrel
2010-09-23
10 Adrian Farrel
AD review

Hi,

I have performed an AD review of your draft.

Don't panic!

I review all drafts that I am responsible for before putting …
AD review

Hi,

I have performed an AD review of your draft.

Don't panic!

I review all drafts that I am responsible for before putting them forward for IETF last call. The main objective is to catch nits and minor issues that would show up during the last call or in IESG review. The intention is to help polish your document and make sure it is clean and shiny so that other reviewers will stick to the technical details.

Most of my comments are pretty trivial, but a couple have more meat on them and I'd like to see a quick respin of the document before I issue the IETF last call. As soon as I see a new revision posted, I'll set the ball in motion.

Of course, all of my issues are up for discussion.

Thanks for the work,
Adrian

---

The RFC Editor is a little sensitive around the boilerplate for RFC 2119
terms.

In Section 2 you have:

  In this document, the key words "MUST", "MUST NOT", "REQUIRED",
  "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
  and "OPTIONAL" are to be interpreted as described in RFC 2119
  [RFC2119].

idnits points out that the standard boilerplate is:

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
  this document are to be interpreted as described in RFC 2119
  [RFC2119].

Can you make the change?

---

Can you confirm that there is no requirement to include an IETF Trust
Legal Provisions of 28-dec-2009, Section 6.c(iii) paragraph? In other
words, can you confirm that no disclaimer for pre-RFC5378 work is
required?

You may be OK with this, but it is good to check.

---

Acronyms

It is easy to get so wrapped up in our own technology that we forget that some of our readers may be less familiar with the acronyms.

The RFC Editor requires that all acronyms except for the ones marked with an asterisk at their web page
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt are expanded:
- on first use in the Abstract
- on first use in the rest of the document

Could you take care of this, please.

---

Section 1

  It is critical that each router select the same 'RP' for a specific
  multicast group address. This RP address may correspond to a
  different physical router but it is one logical RP address and must
  be consistent across the PIM domain.  This is usually achieved
  by using the same algorithm to select the RP in all the PIM routers
  in a domain.

In this document you are defining a new algorithm. Unless you are proposing a simultaneous upgrade of all nodes in the network, this is going to result in two different algorithms being in use at the same time in the same domain.

You need to address this point at the very least by explaining that your new algorithm will produce the same results as the old algorithm so there is no problem with them both running in the same domain.

But wait! If the new algorithm produces the same result as the old
algorithm, why is it needed? :-)

So, I'm a bit confused :-(

- Is this document updating 4601 by replacing the algorithm?
- Is this document updating 4601 by providing a second algorithm?
- Is this document simply providing an optional second algorithm?
- How does interworking work? I.e., what are the backward
  commpatibility issues and solutions?

The way to address this probably by adding backward compatibility in your migration situations in "5. Common use cases".

It looks like the point of the draft is that vendors have different
algorithms in choosing an RP today, so for multivendor environments it would be good to have a consistent approach in choosing an RP. This improves the 4601 algorithm but backward compatibility needs to be discussed.

---

Router implementations and MIB modules

In section 1 you have this text:

  PIM-STD-MIB [RFC5060] has defined an algorithm that allows
  administrators to override Group-to-RP mappings with static
  configuration.  But this algorithm is not completely deterministic,
  because it includes an implementation-specific 'precedence' value.

While the RFC does describe an algorithm, I don't think it is an algorithm that a PIM router would use to select the RP, rather, it is an algorithm that a management station can use to work out which node will have been selected as an RP.

But my confusion about the purpose of this document deepens! In section 6 you list in step 2 you have:

2. If the Multicast Group Address being looked up is in the SSM
    range or is configured for Dense mode, no Group-to-RP mapping is
    selected, and this algorithm terminates.  Alternatively, a RP
    with address type 'unknown' can be selected.  Please look at
    section #8 for more details on this.

Now, section 8 is about MIB objects. So it describes how the fact that no Group-to-RP mapping has been selected can be indicated to the management station in the MIB module.

So I think that maybe step 2 of the algorithm should read...

  2. If the Multicast Group Address being looked up is in the SSM
    range or is configured for Dense mode, no Group-to-RP mapping is
    selected, and this algorithm terminates.  The fact that no
    Group-to-RP mapping has been selected can be represented in the
    PIM-STD-MIB module by setting the address type of the RP to
    'unknown' as described in Section 8.

---

Section 3

OLD
  Existing algorithm defined in PIM-SM (Section 4.7.1 in [RFC4601])
  does not consider following constraints:
NEW
  The existing algorithm defined in PIM-SM (Section 4.7.1 in
  [RFC4601]) does not consider the following constraints:

---

Section 4

There seems to be some contradiction between the second and third bullets.

The second says that dynamic mappings override static ones except under
specific circumstances. The third says that dynamically learned mappings are always preferred over static configuration.

I think this needs clarification, perhaps through moving the third bullet to the top of the list and indicating that these are the "general order of preference".

---

Section 6 - Title

Don't be so timid!
You are defining an algorithm, not simply proposing one.

---

Section 6 - nit

  3.  From the set of all Group-to-RP mapping entries, the subset
      whose group prefix contains the multicast group that is being
      looked up, are selected.

s/are selected/is selected/

---

Section 6

  4.  If there are no entries available, then the Group-to-RP mapping
      is undefined.

Does the algorithm also terminate at this point, and does the same rule
about setting the address type in the MIB module to 'unknown' apply?

---

Section 6.

7.  From the remaining set of Group-to-RP Mappings we select the
      subset of the entries based on the origin.  Group-to-RP mappings
      learned dynamically are preferred over static mappings.  If the
      remaining dynamic Group-to-RP mappings are from BSR and
      Auto-RP then the mappings from BSR SHOULD be preferred.

Why this sudden use of "SHOULD". You haven't used 2119 language anywhere
else in the algorithm.

I suggest you change this s/SHOULD be/is/  and add "unless..." to give an explanation of how some other choice might be made.

---

Section 6.

9.  If the remaining Group-to-RP mappings were learned through BSR
      and the PIM Mode of the Group is 'PIM-SM' then the hash function
      will be used to choose the RP.  The RP with the highest
      resulting hash value will be selected.

Could you add a forward pointer to section 10 next to the mention of the
"hash function".

---

Section 7

  Group-to-RP mapping algorithm defined in PIM-STD-MIB [RFC5060] does
  not specify the usage of 'pimGroupMappingPrecedence' and
  'pimStaticRPPrecedence' objects in 'pimGroupMappingTable' table
  clearly.  With the newly proposed algorithm in this document, these
  MIB objects would not be required.  So we propose to deprecate these
  MIB objects from PIM-STD-MIB.  Also the newly proposed algorithm in
  this document MUST be preferred over Group-to-RP mapping algorithm
  defined in either PIM-SM[RFC4601] or in PIM-STD-MIB[RFC5060].

Wow! There is a lot covered in this little section.

a. If you want to deprecate some MIB objects, I think you need more
  than a sentence hidden in this draft. You would need a full
  revision of RFC 5060. A tidier way to handle this would be an
  erratum on RFC 5060 that points out that the objects are not used
  and updates the Description clauses, but doesn't actually deprecate
  the objects.

b. It seems to me that step 5 of the algorithm in the Description
  clause of pimGroupMappingTable *does* mention how the
  pimGroupMappingPrecedence object is used. Similarly, the
  description clause of pimStaticRPPrecedence seems relatively
  detailed. So perhaps what you want is to clarify the Description
  clauses rather than deprecate the objects?

c. What does it mean to "propose to deprecate" in an RFC?

d. s/the newly proposed algorithm/the algorithm defined/

e. See my previous comments about requiring that this new algorithm
  replaces the one in 4601. While you can require that for new
  implementations you would need to:
  - be clear that this document updates 4601
  - carefully consider how you interwork with legacy implementations

f. If you are also updating the MIB module, you will need to indicate
  that this document updates RFC 5060, but I am not sure that this is
  a very good way to go about things. We would need to consult with a
  MIB expert because I find it a bit confusing if we "hide" the
  update to a MIB Description clause in this document.

  But now I am also worried about what 5060 is trying to do with that
  description clause. If the PIM implementation is capable of working
  out the Group-to-RP mapping, why isn't the RP simply made available
  in a MIB object? Why is the management agent required to read the
  whole table and work it out for itself?

---

Section 8.

Previous comments about this section, but is this an update to a Description clause in 5060? If so, again, are you updating 5060? Is this the best way to do it?

---

Section 9

  In practice, it is not usually necessary to run several dynamic
  Group-to-RP mapping mechanisms in one administrative domain.
  Specifically, interoperation of BSR and Auto-RP is OPTIONAL and not
  recommended by this document.

a. Delete "In practice".

b. Are *you* defining that interoperation is OPTIONAL, or is that
  definition elsewhere? If defined elsewhere, please include a
  reference.

c. According to 2119, "NOT RECOMMENDED" == "SHOULD NOT"
  "SHOULD NOT" allows the exceptional "MAY"
    "OPTIONAL" == "MAY"
  So I am not sure that "and not recommended by thus document" adds
  value. Furthermore it is slightly disconcerting since it suggests
  that maybe someone else is maybe recommending it.

---

Section 9

  The algorithm in this document MUST be used.

This is definitely a statement that you are updating RFC 4601

Then in the following paragraph...

  An implementation of PIM that supports only one mechanism for
  learning Group-to-RP mappings SHOULD also use this algorithm.  The
  algorithm has been chosen so that existing standard implementations
  are already compliant.

The "SHOULD" appears to contradict the previous "MUST".

If existing implementations are already compliant with this algorithm then you surely don't need this new specification. I think this is trying to answer all of my backward compatibility issues, but it needs some work to explain the how and why.

---

Section 10

  It is RECOMMENDED that
  network operators configure only one PIM-Bidir RP for each RP
  Priority.

Is this updating RFC 5015?

---

Section 11

  An implementation of PIM SHOULD support configuration to block
  specific dynamic mechanism for a valid group prefix range.

This looks like an update to 4601. Is it?

---

Section 12

I'd suggest that this section will not (should not?) get through review by the Security Directorate. You are proposing a change to the way in which a PIM node operates. At the very least you should consider how the algorithm could be gamed/disrupted and why the protocol is protected (by the standard security mechanisms in 4601). It will turn out that the bottom line is the same (nothing new needs to be done), but your current text is just too terse to prove the point.
2010-09-14
10 Adrian Farrel State Changes to AD Evaluation from Publication Requested by Adrian Farrel
2010-08-16
10 Amy Vezza
PROTO Writeup for draft-ietf-pim-group-rp-mapping
=================================================

http://www.ietf.org/id/draft-ietf-pim-group-rp-mapping-05.txt

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the …
PROTO Writeup for draft-ietf-pim-group-rp-mapping
=================================================

http://www.ietf.org/id/draft-ietf-pim-group-rp-mapping-05.txt

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

Mike McBride is the document shepherd. I have personally reviewed
the document, and believe it is ready for publication as a Proposed
Standard.

(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

The document has undergone thorough review within IETF's Multicast
community.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

No

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

I have no concerns.

(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

There is consensus within the PIM WG to publish the document. While it
has not received wild working group involvement, the participation has
been active with individuals from a variety of vendors and providers.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media
type and URI type reviews?

Yes.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state
If such normative references exist, what is the strategy for their
completion? Are there normative references that are downward
references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure
for them [RFC3967].

Yes. Normative references are all stable documents published as RFCs.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the
IANA registries clearly identified? If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?


The IANA Considerations section exists. It requires no action by IANA.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?


Not applicable.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup. Recent examples can be found in the
"Action" announcements for approved documents.


Each PIM-SM router in a PIM Domain which supports ASM maintains
Group-to-RP mappings which are used to identify a RP for a specific
multicast group. PIM-SM has defined an algorithm to choose a RP from
the Group-to-RP mappings learned using various mechanisms. This
algorithm does not consider the PIM mode and the mechanism through
which a Group-to-RP mapping was learned.

This document defines a standard algorithm to deterministically
choose between several group-to-rp mappings for a specific group.
This document first explains the requirements to extend the
Group-to-RP mapping algorithm and then proposes the new algorithm.
2010-08-16
10 Amy Vezza Draft Added by Amy Vezza in state Publication Requested
2010-08-16
10 Amy Vezza [Note]: 'Mike McBride is the document shepherd (mmcbride@cisco.com).' added by Amy Vezza
2010-07-26
05 (System) New version available: draft-ietf-pim-group-rp-mapping-05.txt
2010-04-26
04 (System) New version available: draft-ietf-pim-group-rp-mapping-04.txt
2010-02-11
03 (System) New version available: draft-ietf-pim-group-rp-mapping-03.txt
2009-09-23
02 (System) New version available: draft-ietf-pim-group-rp-mapping-02.txt
2009-06-25
01 (System) New version available: draft-ietf-pim-group-rp-mapping-01.txt
2008-10-22
00 (System) New version available: draft-ietf-pim-group-rp-mapping-00.txt