Subject: [pim] Comments to rp mapping discussion

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Tue, 29 Jul 2008 09:04:01 -0700

Hi, 

I was listening to the audio of the discussion on 
draft-joshi-pim-group-rp-mapping-01.txt. 

These are my comments. 

Andy

Dino spoke about removing the static override. 
Some clarifications: 

1. Static override currently does not override 
   embedded rp in the draft. This is something I have
   considered but we will take your comment into 
   account. 

2. The static overrride is the way to do "static period". 
   Most implementations don't have a way to easily turn off 
   receiving of dynamic methods without a boundary on every
   router. This is an easier and stronger way to nail down
   the static config. Bill made the point that you would 
   need to add specific mappings for every range and that
   is not practical. 

There was also discussion on the hashing function. 

1. Yes, the hashing function can and should be improved to
   include the RP as John Z implies. 

2. It should be applied to BSR candidate RPs before they are 
   presented to the algorithm described in the draft. 

   We should not apply the hashing function to all the 
   RP mappings at the end of the algorithm. We should just
   use the highest IP address. 

3. There are better methods for load balancing in use today
   than the hashing function. Anycast RP is a better method. 
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 29 Jul 2008 09:06:52 -0700

>    considered but we will take your comment into 

If i understand the meaning of the standards track embedded-RP
RFC, then i thnknothing should override embedded-RP as far
as theIETF is concerned. If vendors want to provide vendor
specific overrides, that's fine, but should then at best be
an option, butnot the IETF defined standard behavior.

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Tue, 29 Jul 2008 09:22:14 -0700

> From: Toerless Eckert (eckert) 
> 

Yes, some global way to turn off embedded RP would be fine. 
And that could be vendor specific. 

Andy

---

From: Pekka Savola <[email-masked]>
Date: Wed, 30 Jul 2008 11:02:43 +0300 (EEST)

> an option, butnot the IETF defined standard behavior.

(I wasn't in the room so I may be missing something..)

FWIW, when I was writing embedded-RP drafts that led to the RFC, one 
of the things that was brought up was whether you could override the 
embedded-RP mapping somehow.  For example by manual configuration (in 
all routers) and/or distributed in BSR.  There was probably some 
reason provided why this would be good flexibility but I can't recall 
it right now.

I personally considered that (i.e. distributing the same [with better 
preference] or more specific prefix information) reasonable 
flexibility for the operator and I don't believe the RFC prohibits 
that.

However, if someone configures least-specific (e.g. ff00::/8) mapping 
information, that should never override embedded-rp behaviour.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 31 Jul 2008 13:04:47 -0700 (PDT)

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.
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Thu, 31 Jul 2008 13:11:04 -0700

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

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. 

Andy

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 31 Jul 2008 13:20:47 -0700 (PDT)

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

---

From: John Zwiebel <[email-masked]>
Date: Thu, 31 Jul 2008 13:33:18 -0700

> BSR or AutoRP. It does not have to be static.

my 2cents... :-)

I'm not quite ready to call it a "pig".   It all depends on how big  
multicast gets.
Right now it is deployed extensively in a few networks (financial) and
'kind of' deployed almost everywhere else.  If ASM continues to dominate
(vs SSM using -my- understanding of the terms vs the view held by some
that SSM is a subset of ASM <sigh>) I could see the hash function being
useful.

There are so many dependencies in this statement, that perhaps it won't
matter.  However, we could easily make the change now, vs. having to
worry about a lot of backward compatibility later.

FWIW: my "views"
   - never deploy BSR and auto-RP at the same time
	(talk about lipstick)  ;-)
   - BSR works a lot better than auto-RP, but this might depend on  
whether or not
	your implementation doesn't support dense mode.
   - The BSR hash doesn't 'hash' in a predictable manner (I think its  
because it includes the RP address)
   - static is fine (great actually) if your network is never going  
to change and you believe that
	multicast is "global" over your network.  (ie, setting up boundaries  
for mcast distribution doesn't
	apply to you.)

I've been happy with the nxos BSR implementation because it rapidly  
redistributes the
correct information.  No need to timeout anything.  All the routers  
in your (my small network)
get all the new info immediately.   This experience may not translate  
to a larger network.

So, we have a lot of time to get it right this time.  I don't think  
there's any need to hurry.
But, if the internet ever becomes the source of HDTV (vs your cable  
provider, a huge
political decision) this -may- become important.

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Thu, 31 Jul 2008 13:51:05 -0700

> With Anycast, those days are long over.

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. 

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

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

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

Andy

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Thu, 31 Jul 2008 13:57:30 -0700

John, 

Some comments inline. 
________________________________

From: John Zwiebel (jzwiebel) 

> (talk about lipstick)  ;-)

Noone would do this as a design. As it says in the draft 
this comes up when companies merge - one is using AutoRP
and one BSR. We need a migration strategy. I've dealt with
this scenario. 

>  - static is fine (great actually) if your network is never going to
change and you believe that 
>    multicast is "global" over your network.  (ie, setting up
boundaries for mcast distribution doesn't
>    apply to you.)
	
Right, BSR doesn't work with scoping. Does that change your
other comment that BSR works better than AutoRP ;-)

Andy

---

From: John Zwiebel <[email-masked]>
Date: Thu, 31 Jul 2008 14:23:53 -0700

> other comment that BSR works better than AutoRP ;-)

Torless contradicts you, but IMHO, whichever -- BSR still works
better for me but that's from a testing perspective when I
don't really care to wait for minutes to see if the changes I've
configured have been transmitted to the rest of the network.

If one is talking about an enterprise, the things I value may not
be important.

:-)