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

[Stig Venaas <stig at venaas.com>]

John Zwiebel 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.

Yes

> There is no RFC standard for Auto-RP.

The way I read it though, one can be compliant without implementing
all the protocols/methods. E.g. Auto-RP is not required.

> 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.

I think I agree with all of this, but I still think it can be useful to
say what the expected behaviour should be if someone has both enabled...

> 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.

I would just expect 232/8 to always be the SSM range. That is what is
standardised. Some routers may allow this to be configured, but since
static configuration is the only choice, there is no need for an
algorithm.

> 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)

That it is undefined does not contradict that use. It just means that
this draft does not define it. It only tries to talk about RP-mappings,
not to do when there are none. At least that is my thinking. Perhaps
there is a better way to phrase this? Something like "this document
does not specify..." or something?

> 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.

IMO the draft does not require auto-RP to be supported, and also if both
are supported, I don't think the draft requires that both can be enabled
simultaneously. It just say that _if_ you have mappings from both, here
is how to resolve it...

> 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.

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.

Stig

> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> pim mailing list
> pim at ietf.org
> https://www.ietf.org/mailman/listinfo/pim