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

["Andy Kessler (kessler)" <[e-mail]>]

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

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.

 

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

I would like to see advertisement of the dense-mode range however you

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

            the RP-type is 'unknown' it means there is no RP.

 

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.

Text-only is too easy to mis-read.

 

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: [e-mail] [mailto:[e-mail]] On Behalf Of
John Zwiebel (jzwiebel)
Sent: Friday, June 26, 2009 12:16 PM
To: [e-mail]
Subject: Re: [pim] I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

 

 

On Jun 25, 2009, at 7:45 AM, [e-mail] wrote:





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

 

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.