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

From: Leonard Giuliano <[email-masked]>
Date: Wed, 1 Jul 2009 12:47:09 -0700

On Mon, 29 Jun 2009, Andy Kessler (kessler) wrote:

-) John> Since the hash is the very last thing, I'd prefer that it not be
-) removed since its already
-) 
-) there.  Rather change it to a "MAY" requirement.  I'd hate to see it
-) removed only to 
-) 
-) find it has to be added back in again.
-) 
-)  
-) 
-) Andy>- The hash can't be a 'MAY' because different implementations need
-) to be compatible. 
-) 
-)  We asked in several forums if anyone was using the hash and didn't find
-) anyone that wanted
-) 
-)  to continue using it. We also received support for removing the hash
-) when this was discussed
-) 
-)  on this list previously. It will not come back if this draft is
-) accepted. 
-) 

Why again should the hash be deprecated?  Of all of the objectional 
things about BSR, the hash seems pretty low on the list.  Is it worth 
breaking backward-compatibility just to remove this fairly innocuous 
mechanism?

-Lenny

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Wed, 1 Jul 2009 14:21:24 -0700

-----Original Message-----
From: Leonard Giuliano [mailto:[email-masked]] 

-) John> Since the hash is the very last thing, I'd prefer that it not
be
-) removed since its already
-) 
-) there.  Rather change it to a "MAY" requirement.  I'd hate to see it
-) removed only to 
-) 
-) find it has to be added back in again.
-) 
-)  
-) 
-) Andy>- The hash can't be a 'MAY' because different implementations
need
-) to be compatible. 
-) 
-)  We asked in several forums if anyone was using the hash and didn't
find
-) anyone that wanted
-) 
-)  to continue using it. We also received support for removing the hash
-) when this was discussed
-) 
-)  on this list previously. It will not come back if this draft is
-) accepted. 
-) 

-Lenny

Hi Lenny, 

Routers can learn group to RP mapping information from several sources
including statically assigned, BSR, AutoRP and embedded RP. The purpose
of 
this draft is to develop a deterministic way to select a particular
mapping
when we have a conflict. It doesn't have anything to do with advertising
those mappings. 

The problem with the hash function is that it only applies to BSR. How
do 
you apply the hash across static RP or any of the other methods ? We
debated 
at one point in saying that the BSR code itself could use the hash and
then decide
which mappings it would present to the common group to RP mapping table.
Then we
thought it would be best just to drop it and recommend Anycast RP. We
discussed
this on the list. 

Last year about this time you said that you agreed that Anycast is a
better
method for load balancing than the hashing function. You still agree
with that, 
right ? 

I personally would never implement a network with the BSR hash. I'd want
to 
which RP was responsible for which group - even if there was load
sharing
with Anycast. 

Andy

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 2 Jul 2009 11:59:35 -0700

Andy- to be clear, last year I suggested deprecating BSR, not just the 
hash, as Static Anycast is a much better approach.  However, if you are 
unwise enough to use BSR, the hash doesn't seem like a terribly offensive 
way to load balance among multiple RPs.

I am not following you on the problem with the hash's applicability to 
other mechanisms.  The hash is just a tiebreaker within the BSR mechanism.  
I don't see why it needs to be applicable to static or Auto-RP, just as 
local-pref is only applicable to BGP and means nothing to 
ISIS/OSPF/Static/etc.  What am I missing?

On Wed, 1 Jul 2009, Andy Kessler (kessler) wrote:

-) 
-) Hi Lenny, 
-) 
-) Routers can learn group to RP mapping information from several sources 
-) including statically assigned, BSR, AutoRP and embedded RP. The purpose 
-) of this draft is to develop a deterministic way to select a particular 
-) mapping when we have a conflict. It doesn't have anything to do with 
-) advertising those mappings.
-) 
-) The problem with the hash function is that it only applies to BSR. How 
-) do you apply the hash across static RP or any of the other methods ? We 
-) debated at one point in saying that the BSR code itself could use the 
-) hash and then decide which mappings it would present to the common 
-) group to RP mapping table. Then we thought it would be best just to 
-) drop it and recommend Anycast RP. We discussed this on the list.
-) 
-) Last year about this time you said that you agreed that Anycast is a 
-) better method for load balancing than the hashing function. You still 
-) agree with that, right ?
-) 
-) I personally would never implement a network with the BSR hash. I'd 
-) want to which RP was responsible for which group - even if there was 
-) load sharing with Anycast.
-) 
-) Andy
-)

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Sun, 5 Jul 2009 22:21:26 -0700

Lenny, 

Yes, what you describe is what I was suggesting in my first reply
- that BSR applies the hash function to its mapping cache before
they are added to the common group-to-rp mapping table. 

We could go ahead and specify that in this draft and it might 
be fine. However, these are some of the other issues we should 
consider: 

o There are complications with creating hardware forwarding entries
  with PIM-Bidir maybe PIM-SM if the hash is used

o We want to clarify Section 4.7.1 and 4.7.2 of RFC 4601 which 
  describes the steps for group to RP mapping and use of the
  hash function. We are trying to improve the algorithm to also 
  consider: 

  - the origin of a group-to-rp mapping 
    (e.g. bsr, autorp, static, etc)

  - Allow for static override

  - Allow for higher priority of PIM-Bidir over PIM-SM which is
    described in section 3.3 of RFC 5059 [BSR]

Removing the hash from the group-to-rp mapping algorithm makes sense
for these reasons. But if we can come up with some language to describe
how the hash will be applied for BSR mappings and not in the general
case
- we may be open to that approach. 

Andy

-----Original Message-----
From: Leonard Giuliano [mailto:[email-masked]] 
Sent: Thursday, July 02, 2009 12:00 PM
To: Andy Kessler (kessler)
Cc: [email-masked]
Subject: Re: [pim] I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

Andy- to be clear, last year I suggested deprecating BSR, not just the 
hash, as Static Anycast is a much better approach.  However, if you are 
unwise enough to use BSR, the hash doesn't seem like a terribly
offensive 
way to load balance among multiple RPs.

other mechanisms.  The hash is just a tiebreaker within the BSR
mechanism.  

-) 
-) Hi Lenny, 
-) 
-) Routers can learn group to RP mapping information from several
sources 
-) including statically assigned, BSR, AutoRP and embedded RP. The
purpose 
-) of this draft is to develop a deterministic way to select a
particular 
-) mapping when we have a conflict. It doesn't have anything to do with 
-) advertising those mappings.
-) 
-) The problem with the hash function is that it only applies to BSR.
How 
-) do you apply the hash across static RP or any of the other methods ?
We 
-) debated at one point in saying that the BSR code itself could use the

---

From: John Zwiebel <[email-masked]>
Date: Fri, 17 Jul 2009 11:48:57 -1000

On Jun 25, 2009, at 7:45 AM, [email-masked] wrote:

> This draft is a work item of the Protocol Independent Multicast  
> Working Group of the IETF.
>
> 	Title		: PIM Group-to-RP Mapping
> 	Author(s)	: B. Joshi, A. Kessler, D. McWalter
> 	Filename	: draft-ietf-pim-group-rp-mapping-01.txt
> 	Pages		: 19
> 	Date		: 2009-6-25

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.

---

From: Stig Venaas <[email-masked]>
Date: Sun, 19 Jul 2009 05:59:15 +0200

John Zwiebel wrote:
[...]
> 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.

> 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

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

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 lack of a method of specifically advertising an SSM and/or a Dense
> range is 
> found that it is undefined.  This contradicts past use of both auto-RP
> and BSR which

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?

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

> It is extremely easy to set up cases where conflicts in which group ranges
> 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.
> 
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Sun, 19 Jul 2009 08:07:42 -1000

> If you think it does, then we have a problem and we must make that  

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?

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Tue, 21 Jul 2009 00:47:12 -0700

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

 

in the draft.

	is how to resolve it...

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.

than an RFC.  

I understood you to say, "if you support auto-rp you need to follow this
draft."

in test situations, where the allocation of groups in the BSR and those
in

I'll grant you my test cases were probably unrealistic.  But if you make
the case

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

then remove auto-RP?

SSM and dense?

---

From: Stig Venaas <[email-masked]>
Date: Tue, 21 Jul 2009 01:13:51 -0700

Andy Kessler (kessler) wrote:
> 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
> 

I think you could make a more general statement saying that the draft
does not imply implementation of any of the mapping mechanisms, but that
it provides a deterministic way to resolve...

Stig

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Tue, 21 Jul 2009 01:19:48 -0700

Comments below...

----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Tuesday, July 21, 2009 1:14 AM
To: Andy Kessler (kessler)
Cc: John Zwiebel (jzwiebel); [email-masked]
Subject: Re: [pim] I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

some

Stig

Andy> John is not directly concerned about the implementation of the
mapping
Andy> mechanisms but rather that they are required to run together. We
are 
Andy> saying that it is not required or recommended.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 21 Jul 2009 01:31:09 -0700

> Andy> saying that it is not required or recommended. 

Yes, but I don't want people to think that they have to implement say
static override either. There are even implementations that have just
one mechanism, and that should also be fine.

Stig