Subject: [pim] A neophyte's confusion

From: Roger Lin <[email-masked]>
Date: Sat, 10 May 2003 12:51:53 -0700

Hi,

  I am beginner to routing/multicasting, so please don't shoot me before
I have the chance
to air my confusion, and hopefully someone will answer my questions
regarding PIM-SM even if they don't
make much sense.

  (1). There seems to be a disconnect between DR election policy (based
on dr_election_priority
  and higher ipaddr) and underlying unicast selection of nexthop router:

  MRIB.next_hop(S), based on routing metric. Let's ignore
dr_election_priority since it
  is an override tool for administrators to play favoritism, but that
still leaves ipaddr
  to face metric. The winner at the ipaddr game is not necessarily
better at the metrics,
  so we end up with the possibility that the DR may not be the
MRIB.next_hop(S).

  This means that if there are both local membership and downstream join
state on interface I,
  then both the DR and the winner of MRIB.next_hop(S) will try to
forward data on I, and
  they will have to fight it out using assert mechanism, which was
really
  designed for dealing with inconsistent MRIB entries and RPT/SPT
conflict.

  If MRIB.next_hop were used instead of ipaddress of routers in DR
election, we could
  cut down some unnecessary use of asserts; why is MRIB.next_hop not
used?

  (2). The PIM-SM draft never mentions that multicast source S not be
more than single-homed
  (meaning connected only to a single multicast-capable interface); If
they are allowed to connect
  to more than one, then there will be more than one DRs doing
register/encapsulation to RP,
  and since RPs don't make sure that all register pkts from S come from
the same DR, they will
  forward more than one copies of data pkts down the RP trees.

  Is it a given that multicast sources be single-homed?

Best Regards,

Roger Lin

_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Sat, 10 May 2003 14:45:01 -0700

>   and higher ipaddr) and underlying unicast selection of nexthop 

A PIM DR has nothing to do with unicast metrics.  Its just a way of
selecting a single router on a lan to be the system that makes
the decisions for that LAN.

The DR isn't necessarily responsible for forwarding packets on
to a LAN.  It won't if the unicast metrics have the DR join toward
the source through the interface it was elected DR on.

If there is a case where there are two routers forwarding, then
yes an assert happens.

In the scenerio you describe
It would be rare for a down stream router to select a next hop
that wasn't the DR since most often then the DR would also
select the same router as its next-hop.  Not always.

And why complicate selection of the DR to save a couple of asserts?

>   Is it a given that multicast sources be single-homed?

The source doesn't have to be single-homed, but when was the
last time a multi-homed source used the same IP address on
more than one interface?

That would cause unicast routing problems as well wouldn't it?

---

From: Roger Lin <[email-masked]>
Date: Sat, 10 May 2003 15:41:15 -0700

John,

  Thanks for the rapid response.

  With regard to item (2), I was refering to multiple interfaces on the
source
host, each with its own IPAddress.

  On item (1), the DR on a downstream interface will decide to forward if
there
are local membership on the particular interface, regardless whether a
downstream
router (which regards the interface as upstream) decide to do join(*,G) or
join(S,G) to another router on the interface, since the DR's include(*,G)
or include(S,G) macro will become true on the interface, which will cause
its inherited_olist
on the interface to go true, too, forcing it to become a forwarder onto the
interface
for G.

  I am simply saying that it seems to be so natual for DR to use unicast
routing metric
toward S to decide the DR instead of their respective IPAddress.

Best regards,

Roger Lin

---

From: John Zwiebel <[email-masked]>
Date: Sat, 10 May 2003 16:04:40 -0700

On Saturday, May 10, 2003, at 03:41 PM, Roger Lin wrote:\

> toward S to decide the DR instead of their respective IPAddress.
After the DR is selected it does use the unicast metric to send joins
toward the source.  You don't want to have to select a different
DR for every source.

My point was, how do you determine the next-hop is you don't have
a source?  You might say, select the DR based on the metrics toward
the RP, but then what if there are multiple RPs?

PIM DR selection is similar to the OSPF DR selection.  It most often
doesn't matter which router is selected as the DR just as long as
someone is.

Your challenge is to provide a topology where it matters and then
to show that this topology happens often enough that it is important
to change the way DRs have been selected for over 10 years.  And
then you have to show that its important enough that as we deprecate
ASM and move toward SSM and bi-dir that the change is going to
bare fruit.

I think you can see you are up against an awful lot of inertia.

---

From: Roger Lin <[email-masked]>
Date: Mon, 12 May 2003 11:00:18 -0700

I also realized after replying to you Saturday that since PIM's DR selection

is per interface, not per (source, interface) as in the case of Default
Forwarder selection in DVMRP, it is simply not correct to use MRIB.next_hop
to do selection.

Any thoughts on my question about multuple DR(SUBNET_OF(S))?

Best regards,
Roger

---

From: John Zwiebel <[email-masked]>
Date: Mon, 12 May 2003 11:11:00 -0700

> Any thoughts on my question about multuple DR(SUBNET_OF(S))?
If its the question about multiple DRs registering for the same source,
you already answered it.

A multihomed source uses a different IP address for every interface.
PIM uses (S,G) to determine the source.  If a source is sending the
same content using different IP addresses, there's no way for PIM
(or for that matter any IP based multicast routing protocol) to
determine that the content is the same thing.

In any case, there is no reason to source multiple streams of the
same thing.  That's what multicast is all about.