Subject: Re: [pim] Group-to-RP mapping

From: Stig Venaas <[email-masked]>
Date: Tue, 15 Jul 2008 12:58:42 +0200

Bharat Joshi wrote:
> Hi All,
> 
>       We have submitted a new revision of Group-to-RP mapping draft. We have added some common use cases in this revision and also refined the algorithm a little more.
> 
>       Draft is available at: http://www.ietf.org/internet-drafts/draft-joshi-pim-group-rp-mapping-01.txt
> 
>       Please do let us know your comments on this draft.

Here are some comments.

Should abstract and introduction mention bidir and not just pim-sm?
The document covers both.

In the Introduction you write:
    Multiple mechanisms exist today to create and distribute Group-to-RP
    mappings.  Each PIM-SM router may learn Group-to-RP mappings through
    various mechanisms.

Perhaps should point out somehow that a router may be simultaneously
using multiple mechanisms? The above could be read as each router only
using one specific mechanism out of several?

You also write:
    PIM-STD-MIB [2] has defined an algorithm that allows administrators
    to override Group-to-RP mappings with static configuration.  But this
    algorithm is not completely deterministic, because it includes an
    implementation-specific 'precedence' value.

I don't mind having a precedence if it is configurable. It's good to
have standard defaults though. Although it may be simpler to drop it.

In section 3:
   o  It does not provide the flexibility to give higher priority to a
       specific PIM mode.  For example, an entry learned for PIM-BIDIR
       mode is treated with same priority as an entry learned for PIM-SM.

Is it really a matter of priority? Or should it be like every mapping
being either a BIDIR or a PIM-SM mapping and that one for a given mode
should only consider mappings for that mode? That is, keeping two
completely disjoint sets of mappings. I guess you also should say that
embedded-RP only applies to PIM-SM.

In section 4 you only talk about using hashing for BSR (which I think is
what several implementations do), while in your algorithm you use it for
all. I think it is nice to do hashing anyway though...

Is it right to put "other mapping method" beneath static? I assume
"other" would not be static, hence dynamic. Shouldn't it then be
right after the other dynamic methods?

In section 6, see my comments above on mode and hashing regarding
6.6 and 6.8.

Stig

> Regards,
> Bharat
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 16 Jul 2008 10:39:57 +0530

Hi Stig,

> >       Please do let us know your comments on this draft.

Thanks a lot for taking a look at this draft.

> The document covers both.

Ok. Yes, The document covers both.

> using one specific mechanism out of several?

Ok. I can change this.

> have standard defaults though. Although it may be simpler to drop it.

If all the implementation supports a configurable value for this, it
might be good but I think that may not be possible.

> completely disjoint sets of mappings. 

The question is that when a group being looked up in Group-to-RP
mappings, which mode do we prefer? If a box has some configuration which
says that a specific group needs to be used as SM or BIDIR, things will
be better but do we really have such configurations?

> I guess you also should say that

Ok.

> all. I think it is nice to do hashing anyway though...

Actually PIM-SM spec does not say that it needs to be done only for BSR
thats why we also kept it for all.

> right after the other dynamic methods?

Yes.

> In section 6, see my comments above on mode and hashing regarding

Ok.

Regards,
Bharat

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Christopher Thomas Brown <[email-masked]>
Date: Wed, 16 Jul 2008 01:41:34 -0700

> > In section 6, see my comments above on mode and hashing regarding

Correct me if I am wrong, but I don't think hashing should be done
for bidir group addresses.

Is not one of the main points of bidir to eliminate signaling? If the
correct RPA is determined by hashing then one cannot forward on a
(*,G/M) entry where G/M is the group range prefix. With hashing one
must signal new group traffic so that a (*,G) entry or perhaps a
(*,G/hash mask) entry may be programmed into hardware. I don't think
that is desirable.

Chris

---

From: Stig Venaas <[email-masked]>
Date: Wed, 16 Jul 2008 11:45:22 +0200

Bharat Joshi wrote:
[...]
> be better but do we really have such configurations?

I believe so. At least with BSR (in 5059) a mapping will be
explicitly marked whether for BIDIR or SM.

Also, when statically configuring mappings in IOS, you specify
explicitly if it is for BIDIR.

Then we have embedded-RP which is only for SM.

Hence I think it makes sense as a first step to only consider the
mappings that are for the particular mode (BIDIR/SM).

If there are implementations where you use the same static config
for both modes, then you could just say that these mappings are for
both modes.

I don't know about Auto-RP though.

I think what I say is reflected in the PIM MIB too, where you for each
mapping specify which mode it is for. Although I didn't study it in
detail now.

Stig

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Wed, 16 Jul 2008 08:44:53 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> 
> Bharat Joshi wrote:
> [...]
> >> In section 3:

Yes, AutoRP, Static and BSR all specify if the mapping is for SM or
Bidir. 
Someday we may change embedded RP to support Bidir - we may come up with
a way to handle the DF election efficiently. 

The point is that there could be conflicting mappings. One for SM and
one
for Bidir. If they are received from different methods (static or BSR)
we
have a precedence. If they are both received from the same method then 
we need to have a preference for the mode. 

We need a deterministic way to select the correct mapping. 

Andy

---

From: Stig Venaas <[email-masked]>
Date: Thu, 17 Jul 2008 19:03:47 +0200

Andy Kessler (kessler) wrote:
[...]
> a way to handle the DF election efficiently. 

Yes, that would be cool :)
> We need a deterministic way to select the correct mapping. 

Agreed. My thinking was flawed regarding the mode,

Stig

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Fri, 18 Jul 2008 12:29:26 -0700

> (*,G/hash mask) entry may be programmed into hardware. I don't think

That is a great point. 

Multiple candidate-RPs with bsr hashing and bidir would require a new
type of g/m mask entry. Not sure how we should handle that - since this
is the way it works with current specs. 

I think the best thing would be to require or recommend that the hash
will
not apply to bidir candidate RPs - but we apply all the other precedence
rules. 

I just checked the bsr rfc and the bidir rfc and I don't see it mentions
this
anywhere. We should probably include/account for it in this draft. 

Andy

---

From: John Zwiebel <[email-masked]>
Date: Mon, 28 Jul 2008 13:02:24 -0700

> is the way it works with current specs.

Stig:

While we are on the subject of RP hashing.
I find the current hash to be disappointing in that
it is rather undeterministic (which is perhaps what you want from a  
hash, but...)

    Value(G,M,C(i))=
    (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod  
2^31

The use of the RP-address in the calculation does not result in
an even distribution of groups across multiple RPs.

In my testing, with as many as 4 RPs, I find that one of the RPs may  
have only
a few groups allocated to it, while one of them might have the vast  
majority of
groups.

IMHO, the RP-hash function should be considered for deletion from the  
spec.

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Mon, 28 Jul 2008 13:34:40 -0700

John, 
 
Yes, the hash function can be improved and that should be considered. 
But we need to have the function standardized so that all routers in a 
domain select the same RP for a group. Right ? 
 
Andy

________________________________

	From: John Zwiebel (jzwiebel) 
	Sent: Monday, July 28, 2008 1:02 PM
	To: Andy Kessler (kessler)
	Cc: John Zwiebel (jzwiebel); Christopher Thomas Brown; Bharat
Joshi; Stig Venaas; [email-masked]
	Subject: Re: [pim] Group-to-RP mapping

		

		Multiple candidate-RPs with bsr hashing and bidir would
require a new

		type of g/m mask entry. Not sure how we should handle
that - since this

		

	Stig:

	While we are on the subject of RP hashing.
	I find the current hash to be disappointing in that
	it is rather undeterministic (which is perhaps what you want
from a hash, but...)

	   Value(G,M,C(i))=
	   (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345)
mod 2^31

	In my testing, with as many as 4 RPs, I find that one of the RPs
may have only
	a few groups allocated to it, while one of them might have the
vast majority of
	groups.

	IMHO, the RP-hash function should be considered for deletion
from the spec.