 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
On Jul 18, 2009, at 5:59 PM, Stig Venaas wrote:
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? |