 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
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: pim-bounces at ietf.org
[mailto:pim-bounces at ietf.org] On Behalf Of John Zwiebel (jzwiebel) On Jun 25, 2009, at 7:45 AM, Internet-Drafts at ietf.org 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. |