Subject: A naive question..

From: Sridhar Vallepalli <[email-masked]>
Date: Tue, 06 Jul 1999 21:49:50 -0400

Why does PIM consult the Unicast routing table?
1)From what I understand this is used for mostly (S,G) entries in the
routing 
table and not for (*,G) entries.
2)I also understand that it is used for setting the iif for a source.
Why 
can't we set the iif as the interface on which we received this
join/prune.
3)And why doesn't DVMRP depend on the unicast routing table like pim
does?

Thanks in advance. 
-sri

---

From: Dave Thaler <[email-masked]>
Date: Wed, 7 Jul 1999 12:47:02 -0700 (PDT)

> Why does PIM consult the Unicast routing table?

Because it doesn't maintain a routing table of its own,
and when PIM was designed, that was the only table available.
Today, what we really mean is that PIM consults the
"multicast RIB" or "multicast view of the routing table",
where one or more protocols like DVMRP, MBGP, etc contribute
routes marked as valid for multicast.

This allows your multicast topology to differ from the
unicast topology, which in some situations is seen as a good
thing.

> routing table and not for (*,G) entries.

It's used for (*,G) entries too.  The routing table is consulted
to find the path to the RP.

> Why can't we set the iif as the interface on which we received this
> join/prune.

Because you receive join/prunes on a downstream interface, and the
iif is the upstream interface on which you want to *send* a join/prune.

> 3)And why doesn't DVMRP depend on the unicast routing table like pim

DVMRP is both a tree construction protocol and a route exchange protocol.
It is able to exchange routes itself to allow the multicast
topology to differ from the unicast topology.

Some implementations also allow using only the route exchange part
of DVMRP, just so that PIM can run over a multicast routing table
which is different from the unicast routing table.

-Dave

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 08 Jul 1999 13:00:28 +0900 (JST)

Dave,

> routes marked as valid for multicast.

It's first time for me to hear that.
Do you mean "PIM should create (or maintain) multiple RIBs which are
unicast and multicast RIB"?
If so, which do you propose it should be a spec matter or an
implementation matter? If you would say "it should be an spec matter",
current RFC as for PIM-SM and I-D as for PIM-DM must be specified
that one, I think.

Anyway, IMHO, multiple RIBs as a spec might be surposed to be
flattering us.:)
Or, are there any unwilling things to have multiple RIBs in PIM spec?

Regards.
--
Hitoshi Asaeda, ITS/IBM-Japan

---

From: Dave Thaler <[email-masked]>
Date: Thu, 8 Jul 1999 00:24:17 -0700 (PDT)

> unicast and multicast RIB"?

It's absolutely not the job of PIM to create/maintain RIBs.  
The creation/maintenance of the RIBs is the job of the route 
exchange protocols.  PIM is merely a tree construction protocol.  
As PIM's name implies, it's independent of whatever protocols you 
use for route exchange.

-Dave

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 08 Jul 1999 16:48:41 +0900 (JST)

> As PIM's name implies, it's independent of whatever protocols you 

Ok. So, I'd like to ask whether you meant future PIM should consult
its multicast RIB which is created in a PIM router (not by PIM
itself:) and is independent of the unicast RIB. If yes, how do you 
feel that function would be included (or cared) in the new spec?

Thanks.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 8 Jul 1999 11:49:51 -0700 (PDT)

> its multicast RIB which is created in a PIM router (not by PIM

Replace "its" with "the" in the sentence above, and then my
answer is yes.  It's not PIM's.  The same RIB is used by all 
multicast routing protocols running on the box.  It's not PIM-specific
(see draft-thaler-multicast-interop-03.txt if you don't understand 
what I mean by multiple multicast routing protocols running).

> feel that function would be included (or cared) in the new spec?

Yes.

-Dave