Subject: [pim] I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

From: [email-masked]
Date: Thu, 25 Jun 2009 10:45:02 -0700 (PDT)

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		: PIM Group-to-RP Mapping
	Author(s)	: B. Joshi, A. Kessler, D. McWalter
	Filename	: draft-ietf-pim-group-rp-mapping-01.txt
	Pages		: 19
	Date		: 2009-6-25
	
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 allow administrator to override a specific Group-
   to-RP mapping with the static Group-to-RP mapping which an
   administrator would want to use.  This algorithm also does not
   consider the PIM mode and the mechanism through which a Group-to-RP
   mapping was learned.

   The intention of this document is to suggest 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-group-rp-mapping-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: John Zwiebel <[email-masked]>
Date: Fri, 26 Jun 2009 09:15:34 -1000

> 	Filename	: draft-ietf-pim-group-rp-mapping-01.txt

FWIW:
Since the hash is the very last thing, I'd prefer that it not be  
removed since its already
there.  Rather change it to a "MAY" requirement.  I'd hate to see it  
removed only to
find it has to be added back in again.

Dense-mode is a problem.  If you are really going to do this reform
I would like to see advertisement of the dense-mode range however you
want to do it.

6.2 You're talking about dense and ssm group ranges.  This doesn't mean
	the RP-type is 'unknown' it means there is no RP.

6.4 talks about being "undefined" doesn't this mean dense-mode?  SSM
	is defined by 232/8 or by statically configuring the ssm-range on  
each router.
	Again, if you're going to go down this path, I'd like the BSR to be  
able to
	advertise an SSM range.  Isn't this the same thing you're talking  
about in 6.2

6.8, There is no way that you can have BSR and Auto-RP interoperate.
	After years of trying and always running into dead ends, there is no  
way
	I could allow this section to remain.  I would prefer that auto-RP  
be decremented.
	Specifically trying to have an RP advertised in both BSR and auto-RP  
really
	gets confused.

I would like to see a decision tree that would more clearly explain  
the choices.
Text-only is too easy to mis-read.

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Mon, 29 Jun 2009 12:57:32 -0700

Hi John, 

Thanks for taking the time to review the draft. 

Here are my responses to your comments. 

Andy

John> Since the hash is the very last thing, I'd prefer that it not be
removed since its already

Andy>- The hash can't be a 'MAY' because different implementations need
to be compatible. 

 We asked in several forums if anyone was using the hash and didn't find
anyone that wanted

 to continue using it. We also received support for removing the hash
when this was discussed

 on this list previously. It will not come back if this draft is
accepted. 

John> Dense-mode is a problem.  If you are really going to do this
reform

want to do it.  

Andy>This Draft does not cover advertisement of group ranges - but
rather how they are stored

in data structures for the MIB and a deterministic algorithm for
selecting an RP from those choices.

Changing how groups are advertised would need to be as part of BSR
protocol changes. 

John>6.2 You're talking about dense and ssm group ranges.  This doesn't
mean

Andy>This is described in Section 8: 

   When an Group-to-RP mapping entry is created in the

   pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be

   acceptable to have an entry with an RP with address type 'unknown'

   and a PimMode of Dense Mode or SSM.  These entries would represent

   group ranges for Dense mode or SSM.

John>6.4 talks about being "undefined" doesn't this mean dense-mode?
SSM

            is defined by 232/8 or by statically configuring the
ssm-range on each router.

            Again, if you're going to go down this path, I'd like the
BSR to be able to

            advertise an SSM range.  Isn't this the same thing you're
talking about in 6.2

Andy>No, we are talking about receiving a Join for a group and then
performing a lookup to

 see which RP (or none) is assigned to that group. If the group is NOT
defined in the SSM range

 on the router, there is no Sparse mode or Bidir RP AND it is not within
the dense mode group

 range - then the Group-to-RP mapping is undefined. The handling of
dense mode as a fallback

 option can be handled as an implementation decision - but it does not
affect the Group-to-RP 

 mapping algorithm. 

Andy>If you want to change the way BSR advertises groups (for example
SSM ranges) then you

need to look at a different draft for the BSR protocol. 

John>6.8, There is no way that you can have BSR and Auto-RP
interoperate.

            After years of trying and always running into dead ends,
there is no way 

            I could allow this section to remain.  I would prefer that
auto-RP be decremented.

            Specifically trying to have an RP advertised in both BSR and
auto-RP really

            gets confused.

Andy>This point in the algorithm actually solves that problem. It
establishes a preference if

 multiple Group-to-RP mappings exist. We are not saying that this is a
preferred deployment

 option - but instead it establishes a deterministic way to pick the
winner. The order of

 preference in the draft is BSR, AutoRP, Static and other. Therefore,
BSR already has preference

 over AutoRP. 

John> I would like to see a decision tree that would more clearly
explain the choices.

Andy>Your idea of a flow chart to show the algorithm is a good one.
Hmmm... in 2009 can we include

  a gif or pdf with our draft ? I suppose we'll do it in ascii. We'll
add that to the next draft. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Zwiebel (jzwiebel)
Sent: Friday, June 26, 2009 12:16 PM
To: [email-masked]
Subject: Re: [pim] I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

This draft is a work item of the Protocol Independent Multicast Working
Group of the IETF.

        Pages           : 19

        Date            : 2009-6-25

FWIW: 

Since the hash is the very last thing, I'd prefer that it not be removed
since its already

want to do it.  

            is defined by 232/8 or by statically configuring the
ssm-range on each router.

            Again, if you're going to go down this path, I'd like the
BSR to be able to

            advertise an SSM range.  Isn't this the same thing you're
talking about in 6.2

            After years of trying and always running into dead ends,
there is no way 

            I could allow this section to remain.  I would prefer that
auto-RP be decremented.

            Specifically trying to have an RP advertised in both BSR and
auto-RP really

            gets confused.

I would like to see a decision tree that would more clearly explain the
choices.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 29 Jun 2009 14:59:09 -0700

Just a quick comment

Andy Kessler (kessler) wrote:
[...]
> John> I would like to see a decision tree that would more clearly 

Sounds like a good idea

>   a gif or pdf with our draft ? I suppose we’ll do it in ascii. We’ll 

What's wrong with ascii? ;) In 2009 you can indeed to pdf (this was done
for PIM and BSR RFCs too, haven't you seen the beautiful FSMs there?).
In the past there have also been RFCs in PostScript, but seems pdf is
the desired non-ascii format these days.

Stig