Subject: [pim]group-to-rp mapping : static RP vs. BSR

From: Ji-Eon KIM <[email-masked]>
Date: Tue, 14 Dec 2004 20:55:08 +0900

Hi! My name is Ji-Eon Kim from KT.

In draft-ietf-pim-sm-v2-new-11.txt, follwoing group-to-rp mapping
algorithm is sugested

1 Perform longest match on group-range to obtain a list of RPs.
2 From this list of matching RPs, find the one with highest priority.
Eliminate any RPs from the list that have lower priorities.
3 If only one RP remains in the list, use that RP.
4 If multiple RPs are in the list, use the PIM hash function to
choose one.

But, if we configure static RP address and receive C-RP addresses from
BSR for same group address with same mask length, which address does the
router select as RP?
For example, Router A has static RP information, RP address 10.1.1.1 for
group 238.1.1.0/24
and has C-RP information from BSR, RP address 10.0.0.1 for group
238.1.1.0/24.
In this case, which RP address will be selected?

With above algothrithm, some router select 10.1.1.1 as RP address and
other routers select 10.0.0.1, even if static RP and BSR RP have same
priority value.
In current state, some vender select RP from BSR, some vender select
Static RP and som vender uses hash function with static RP and RP from
BSR..

So, I think router sould have administrative distance(priority) about
the way the router gets RP address.
This is the similar case as routing protocol. Each router has the
administrative distnace for each routing protocol.

-- 
Ji-Eon Kim  김 지 언
Backbone Network Architecture Division
Telecommunication Network Laboratory
KT Corporation

463-1 Jeonmin-dong, Yuseong-gu, Daejeon 305-811, KOREA
Direct: +82-42-870-8334
Fax: +82-42-870-8339
e-mail: [email-masked]

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Dec 2004 11:54:12 -0800

> and has C-RP information from BSR, RP address 10.0.0.1 for group

Yes, the PIM spec is pretty sneakish here, just talking about priorities
from different sources of information (AutoRP, BSR, static, EmbeddedRP, ...)
and leaving out the piece as to how priorities should be compared.

> administrative distnace for each routing protocol.

The more fundamental problem is that there is no IETF architecture for 
IP multicast group-range mode selection, where mode includes choice
of tree building protocol to use, choice of protocol parameters (eg: RP)
and choice of service mode (ASM or SSM). This is a problem that is outside
the scope of the PIM-SM spec. Because there is no other draft/rfc
for that, the PIM-SM spec took it upon itself to include as much about this
problem as the authors felt was appropriate. The wording used now does
definitely allow for a distance based implementation (it's just a matter
of constructing the "priority" mentioned), but it is of course completely
non-obvious.

I agree that a prefix-length->distance->priority based architecture
is what we need, but i would be careful demanding the flexibility unicast
has because there are too many differences: non-aggregation, non-interdomain
group mapping protocols, RP selection consistency requirements, total
number of prefixes to map, etc.,....

Cisco IOS for example has a mostly fixed distance based architecture,
and it may well satisfy deployment requirement better than a more
flexible (freely reconfigurable distance) approach because of the simplicity
in design and consistency in behavior of routers it enforces.

Given that interdomain RP mapping (except for Embedded-RP) is outside
the scope, intradomain problems (between routers from different vendors) can
typically well be solved by simple best current practices like using only
non-overlapping prefixes such as 239.x/16. All this of course is only
necessary if you can not simply use a single protocol across your domain,
and then my first question is always "why not a single protocol".

If you want to raise this issue further, i would recommend to have this
done in mboned instead of pim: write a problem statement explaining
specific cases where you think there is current underspecification of
cross-vendor interoperability. If the cases are persuasive enough that
they can not be argued away with for example the BCP from the last 
paragraph, then that should lead to the recognized need to improve on
this architectural piece. 

Cheers
	Toerless