 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
On Jun 25, 2009, at 7:45 AM, Internet-Drafts at ietf.org wrote:
This draft is on the standards track. If it becomes a standard then several current implementations could find be found to be non-compliant. There is no RFC standard for Auto-RP. From rfc5110: Cisco's Auto-RP is an older, proprietary method for distributing group to RP mappings, similar to BSR. Auto-RP has little use today. Few, if any, deployments currently use auto-RP and BSR at the same time, Even if two organizations decide to merge, the idea that one has to run auto-RP and BSR at the same time to allow for a smooth transition does not make sense. If an organization is running an image that is so old that it does not support both auto-RP and BSR they have bigger problems than choosing one or the other protocol. (Since BSR is an IETF standard, I would think they would choose BSR.) FWIW: I feel that the BSR protocol is better than Auto-RP. Not a lot better perhaps, but better "enough" for me to always choose it over Auto-RP. But let us assume that there might be a case, where one organization is running auto-RP and another is running BSR. Don't they also have questions about how to allocate and merge SSM and Dense-mode group ranges ranges? For SSM if the group falls in the default SSM range or a group range specifically configured on each router in the domain to be allocated for SSM. In the dense-mode case, it is the absence of an an RP assigned to the group or the group outside of the SSM range, that determines that the router will forward the packet via the dense protocol. The lack of a method of specifically advertising an SSM and/or a Dense range is a problem. Specifically paragraph 6.4 suggests that if there is no group mapping found that it is undefined. This contradicts past use of both auto-RP and BSR which assumed such a group would be Dense (modulo the router being specifically configured for SSM) If the purpose of this Draft is to smooth merging of different organizations, I do not see how you can overlook these problems. The selection order defined in Section 6 does not specify BSR or Auto-RP until step 8. This may require a lot of effort on the part of some operating systems to track both BSR and auto-RP advertisements at the same time and could greatly complicate the current data structures. Give Pekka's statements about the usefulness of both auto-RP and BSR, this is a lot of work for very, very little gain. I have spent a lot of time trying to run both auto-RP and BSR at the same time. It is extremely easy to set up cases where conflicts in which group ranges these protocols are advertising will over-write one another. This draft does not say "MUST" or "SHALL" except in para 7 which is talking about "Deprecation of MIB Objects". Unless there is an RFC for Auto-RP that becomes an internet standard, I do not see how this draft can provide a standard for a mechanism on how to prioritize Unless BSR is always selected over auto-RP no matter what the prefix-length of the group range, again the current proposal will cause many more problems than it will solve. Finally, perhaps redundantly, there is only one IETF standard for automatically distributing group-to-RP mappings and that is the BSR. You cannot write a new RFC that implicitly (if not explicitly) mandates Auto-RP also be supported. |