Subject: Re: [pim] Comments to rp mapping discussion

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Fri, 1 Aug 2008 05:42:48 -0400

> In the days when you only had static vs AutoRP, it made sense to use
BSR.  
> With Anycast, those days are long over. 

Well, this is not entirely true in large networks where static
configuration is very difficult to change and is prone to errors. So,
using Anycast for recovery and BSR for discovery is a useful
combination.

Maria
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Leonard Giuliano
Sent: Thursday, July 31, 2008 4:21 PM
To: Andy Kessler (kessler)
Cc: [email-masked]
Subject: Re: [pim] Comments to rp mapping discussion

On Thu, 31 Jul 2008, Andy Kessler (kessler) wrote:

-) > On Tue, 29 Jul 2008, Andy Kessler (kessler) wrote:
-) > 
-) > -) 
-) > -) 3. There are better methods for load balancing in use today
-) > -)    than the hashing function. Anycast RP is a better method. 
-) > 
-) > Agree with this point here.  We've been tinkering with BSR for
years, 
-) > while it's clearly inferior to the predominantly deployed solution
in 
-) > multiple ways (static anycast).  Let's quit adding lipstick to a
pig.
-) > 
-) > Until someone can come up with a reason where an enhanced BSR 
-) > would give 
-) > you any benefit over static anycast, my suggestion is to not 
-) > bother trying 
-) > to enhance it.
-) 
-) I agree that we don't need the hashing function if we have anycast. 
-) 
-) I'd just like to point out that we can still use anycast with 
-) BSR or AutoRP. It does not have to be static. 
-) 

Sure, you CAN use BSR/AutoRP with anycast, by why would you want to,
other 
than to add needless complexity with no benefit?  

The whole point to anycast is you have a single, shared, virtual address

that need never change.  Why would you need a complex dynamic mechanism
to 
learn an address that will never change?

In the days when you only had static vs AutoRP, it made sense to use
BSR.  
With Anycast, those days are long over.
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 1 Aug 2008 12:51:52 -0700 (PDT)

-) 
-) A couple of your assumptions aren't true. 
-) 
-) The RP is not always a 'single, shared, virtual address that need 
-) never change'. In distributed environments there may be many RPs
-) for specific applications. Some of the apps may be best for Bidir
-) and some for PIM-SM. The RPs are located in geographic locations
-) which optimize the distribution. Different groups own the RPs - the 
-) only administration that is shared is coordination of the group
-) addresses. 
-) 

And all of these apps could be addressed with msdp policy, regionalized 
sets of anycast RPs, etc.  Even Bidir could get redundancy with floating 
anycast RPs.

-) Anycast allows for redundancy as well as load sharing. 
-) Anycast should always be used for redunancy rather than BSR or
-) AutoRP. 

So BSR/AutoRP users don't need redundacy?  I wouldn't mind working in that 
NOC...

And these networks that don't care about redundancy are complaining about 
the hashing function?  And for all those BSR Anycast networks, hashing 
isn't an issue.

-) 
-) AutoRP and BSR bring to the table a way to learn several RP mappings
-) across thousands of routers in a manageable way. 
-) 

First, any network with hundreds/thousands of routers most likely have 
provisioning systems that would push down a single line of config to all 
routers and probably do so much faster than BSR/AutoRP could converge.

Second, the implication that BSR/AutoRP are zero-config on the clients is 
not necessarily true.  In the event that you did have to change the BSR or 
C-RP, you'd probably have to go in and touch all the routers BSR/AutoRP 
filters.

Finally, anyone who's ever experienced the joy of tshooting a BSR/AutoRP 
problem will tell you afterwards that saving one line of config isn't 
worth the pain of fixing BSR/AutoRP when it breaks.

-) Yes, I usually prefer static rp. But there are situations in which
-) a dynamic method makes sense.
-) 

Enterprises and financials often do odd things, like statically flooding 
all traffic at their borders instead of simply running MSDP.  Their 
explanation is usually something along the lines of "Because that's what 
the whitepapers and consultants told us to do in 1995 when we first built 
this network."  This, btw, is the rationalle I've heard from every AutoRP 
customer I've ever worked with.

"Doc, it hurts when I do this" is usually responded to by the doctor with 
"Then don't do that", rather than "Let me find you a more efficient way to 
hurt yourself."

If someone really wants to use BSR, they are free to do so.  My suggestion 
is that we not waste our time trying to add enhancements like a better 
hashing algorithm.  I would say this is analogous to trying to enhance 
MSDP at this time.
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Fri, 1 Aug 2008 12:59:15 -0700

> hashing algorithm.  I would say this is analogous to trying to enhance

I want to see MSDP die.  :-)
So its not quite the same.

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Fri, 1 Aug 2008 14:59:05 -0700

> From: Leonard Giuliano [mailto:[email-masked]] 
> 
> So BSR/AutoRP users don't need redundacy?  

RPs should be backed up with Anycast. 
BSR and AutoRP should use Anycast and multiple mapping
agents/BSRs for redundancy. 

> My suggestion 
> hashing algorithm.

We agree. I'd be happy to drop hashing altogether. 

Andy

---

From: John Zwiebel <[email-masked]>
Date: Fri, 1 Aug 2008 16:09:04 -0700

> We agree. I'd be happy to drop hashing altogether.

One or the other, drop it or make it better.
Don't leave it as it is.