 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Ok,
we didn’t intend to restrict or clarify how people should deploy autorp,
bsr, static
or embedded rp – but if you think that is relevant we can add some language
in a new section like this:
Use of dynamic group-to-rp mapping protocols
Generally it is not necessary or recommended to run multiple dynamic group-to-rp
mapping
protocols in one administrative domain. Specifically, there is no interoperation
of BSR
and AutoRP implied or recommended by this draft. However, if a router was to
receive two
sets of group-to-rp mappings from AutoRP and BSR, such as may be the case on a
border
router between two domains or perhaps through a misconfiguration this draft
creates a deterministic
way to resolve the conflict and select one group-to-rp mapping. This is necessary
for consistency and stability of the network across the PIM domain. Further,
SSM ranges *are* completely covered in this draft. Section 8 describes
how the SSM
group ranges are stored in the “SSM Range Table” in the IP Mcast
MIB and that those ranges
are copied over to the pimGroupMappingTable which is what is being
searched by this proposed algorithm. If the group that is being looked up, falls in the SSM
range or the range that is configured for dense mode then the *RP*
will have an address type of ‘unknown’. The group will
still be valid for SSM. Please let me know if this clears up the remaining issues
with the draft. Andy From: pim-bounces at ietf.org
[mailto:pim-bounces at ietf.org] On Behalf Of John Zwiebel (jzwiebel) On Jul 18, 2009, at 5:59 PM, Stig Venaas wrote:
I completely agree, but I don't think this draft
implicitly mandates it. If you think it does, then we have a problem and
we must make that clear in the draft. If I didn't think support of Auto-RP was mandatory to
implement this proposal, then I wouldn't have any problems with it. On the other hand, I would wonder why one would bother
writing it.
I didn't read any "..if.." I support the idea of defining a better method of selecting
group to RP mappings. But if you are going to do that, then I think it better to
not leave any holes. Given what Pekka said in 5110, perhaps a BCP would be a
better approach than an RFC. Also, it isn't clear if this is suppose to be a standard or
just informational. If it is a standard, I would remove support for auto-RP from
my OS so I wouldn't have to worry about ensuring that they work well
together. I understood you to say, "if you
support auto-rp you need to follow this draft." Given my experience with auto-RP and BSR at the same time,
granted only in test situations, where the allocation of groups in the
BSR and those in auto-RP overlap each other and have wildly different
prefix-lengths, I would never deploy auto-RP and BSR at the same time. I'll grant you my test cases were probably unrealistic.
But if you make the case to me simpler then it would be just as easy to deploy only
one protocol when merging organizations. Ie, in the simplest case,
two organizations might define only 224/4 for the single RP for each
organization. If one is running BSR and the other is running auto-RP, given the
algorithm defined in this proposal, the BSR RP would always be chosen anyway.
And if one organization runs BSR while the other auto-RP, if this draft is followed, you'll have to configure auto-RP in the BSR
routers and BSR in the auto-RP routers. Wouldn't it be easier to deploy BSR
everywhere and then remove auto-RP? WRT dense-mode and ssm, I'm only saying that I view the
purpose of this draft to clearly define how group ranges are allocated.
Why not include SSM and dense? |