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

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

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: [e-mail] [mailto:[e-mail]] On Behalf Of
John Zwiebel (jzwiebel)
Sent: Sunday, July 19, 2009 11:08 AM
To: Stig Venaas
Cc: [e-mail]
Subject: Re: [pim] I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

 

 

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.

 

	 It just say that _if_ you have mappings from both, here

	is how to resolve 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?