Subject: PIM-SM: muti-netting problem for JP messages

From: Ardas Cilingiroglu <[email-masked]>
Date: Mon, 21 Dec 1998 11:20:46 -0500 (EST)

Hi,

Consider the following scenario:

     R                         ~~~RP
     |                         |
   +---+                     +---+
   | X |                     | Z |
   +---+                     +---+
     |                         |
   -------------------------------
                  |
                +---+
                | Y |
                +---+

Routers X, Y and Z are on the same multi-access network, 
where X and Y share a subnet, and Y and Z share another one.
To reach to RP, X has Y and Y has Z as next-hop.

The problem that I see is that, when router X receives a local-
receiver for G, it will send a Join request for (*,G) to router
Y. But, router Y will not forward this Join request to router
Z, since (*,G) entry that will be created in Y will have a
NULL oif list.

Is this really the case?

thanks,
Ardas

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Mon, 21 Dec 1998 09:47:30 -0800

> Consider the following scenario:

I think, no. If I remember correct, the spec doesn't say that a
"NULL oif" check has to be performed before forwarding the Join
message. The Join message will be forwarded to Z, but the (*,G)
state Y creates will have NULL oif list.

Pavlin

---

From: Shahzad Ali <[email-masked]>
Date: Mon, 21 Dec 1998 13:25:51 -0500 (EST)

hi,

> state Y creates will have NULL oif list.

I couldnt find any mention of "forwarding" join prune messages.  Either
you periodically originate them or trigger them due to certain events.  So
in this case, a new entry created will trigger a join prune message but
its content can be totally different from the join prune message which
triggered it.  If the oiflist is NULL, then I think, a prune is supposed
to be sent up ( at least according to the spec), which does not seem like
the correct thing to do.  So, in a sense, the join will not sent up and
therefore the problem. 

In this case, however, I feel that there should be a mechanism to
distinguish the multi-netted interface on Y so that the incoming interface
and the outgoing interface for the entry at Y are different at least
virtually. I cant see Y forwarding any traffic to X also unless there is
such a provision. Thus the 

Question: How do you intend to forward traffic from Z to X via Y if the
entry at Y has a NULL oiflist?

-Shahzad

---

From: Ahmed A-G Helmy <[email-masked]>
Date: Mon, 21 Dec 1998 10:39:05 -0800 (PST)

> state Y creates will have NULL oif list.

hmm.. not sure about the scenario above... if Y is the DR to the LAN and 
it has R as directly connected rcvr, then it would create *,G w/ null oif 
and forward the join to Z on the same iif, cuz the RP's RPF is reached 
via that interface... that's in the spec.
	how does the above scenario occur if the unicast routing 
converges on a single RPF towards the RP for the lan !?

-A

---

From: Ahmed A-G Helmy <[email-masked]>
Date: Mon, 21 Dec 1998 10:58:46 -0800 (PST)

> such a provision. Thus the 

Ah... I think I understand the problem now.
... yes... u can solve the problem in this case by using a virtual 
interface as mentioned above (since unicast also uses this virtual 
interface to forward the pkts I presume.. !! ).So, the oif list will not 
be null.
	in forwarding packets, the packets, I presume that pkts from Z to 
Y are not received by X, ... while Y's pkts forwarded on the subnet to X 
are the only ones rcvd by X.
so u can look at this case as virtually being 2 lans:

R
|
X
|
Y
|
Z
|
RP

Regs,
-A

---

From: Dave Thaler <[email-masked]>
Date: Mon, 21 Dec 1998 15:11:43 -0500 (EST)

> entry at Y has a NULL oiflist?

Unless you take steps to prevent it,
X will get packets directly from Z.

The source and destination IP addresses are the same as if the
packet were relayed via Y.
The link-layer destination address is the same
(being the Ethernet mapping of the group address, if Ethernet).
The link-layer source is the same, but this isn't used in multicast
forwarding.

-Dave

---

From: Shahzad Ali <[email-masked]>
Date: Mon, 21 Dec 1998 15:20:12 -0500 (EST)

> X will get packets directly from Z.

The issue here is basically what X does with the packets that it receives
directly from Z.  I agree that these packets are the same as the ones it
would have received via Y, but unless X has an entry for these packets,
they are useless.  The only way to get an entry is to get the join/prune
from X either directly or indirectly to Z.  The join_prune has an upstream
address and unless that is correct, we dont process the Join-prune.  So if
X sends a  join_prune to Y, Y has to install an entry and send a
join_prune to Z for packets to be forwarded along this path.  Otherwise,
if X's join_prune doesnt get to Z because Z isnt the upstream and Y
"doesnt" send a join_prune, we are in trouble.

Am I missing something?

-Shahzad

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Mon, 21 Dec 1998 12:16:42 -0800

> the correct thing to do.  So, in a sense, the join will not sent up and

Yes, you are right (I did not finish my morning coffee when I wrote
my email :)

In this case Y should use different virtual interfaces with regard
to the different subnets Y-X and Y-Z. These different vifs should
also be used in the routing table state, and therefore the routing
state will be with non-NULL oifs. When a forwarding entry needs to
be installed in the kernel (or whatever), if a virtual oif and the
iif correspond to the same physical interface, this virtual oif is
not included in the forwarding entry (the only exception is when the
vif iif is the register vif).

This solution, of course, assumes that the multicast traffic is seen
by all virtual LANs on the same physical wire, so Y does not need to
forward it from Z to X (see the email by D. Thaler)

Not sure whether the spec needs to describe how to deal with such
virtual lans, or it is implementation issue.

> and the outgoing interface for the entry at Y are different at least

Y will have different unicast IP addresses for different virtual
LANs. This will define your vifs wrt the Joins.

Pavlin

---

From: Shahzad Ali <[email-masked]>
Date: Mon, 21 Dec 1998 15:25:55 -0500 (EST)

Hi,

> vif iif is the register vif).

I think this is a way of getting around the solution but dont know if it
is "the" way.

> forward it from Z to X (see the email by D. Thaler)

Correct and as I mentioned in my reply, that still needs a entry created
by the join_prune message from Y on Z.  To summarize: 

1) To forward, if the incoming interface and an oif are on the same
physical LAN, we will not forward on that oif.  

2) We will continue, however, to send periodic join_prunes to Z
nonetheless.

> virtual lans, or it is implementation issue.

I believe this is an implementation specific issue and is better kept out
of the spec.  

-Shahzad

---

From: Dave Thaler <[email-masked]>
Date: Mon, 21 Dec 1998 15:25:38 -0500 (EST)

> vif iif is the register vif).

Right.  If I remember correctly, we made gated-5.0 do exactly
what you described above.  I know I ran some multi-netting tests
with DVMRP in gated over a year ago, and the problem is more or 
less the same as in PIM.

-Dave

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Mon, 21 Dec 1998 12:36:45 -0800

> by the join_prune message from Y on Z.  To summarize: 

Right. You need the entry in Y so Y can act as a "relay" for the J/P
messages between the two different virtual LANs. If you want to
avoid these entries in Y, then you may need some explicit
configuration between X and Z so X can send directly PIM messages to
Z. The extra entries in Y is the way to avoid the explicit
configuration.

Pavlin

---

From: Ahmed A-G Helmy <[email-masked]>
Date: Mon, 21 Dec 1998 14:45:30 -0800 (PST)

> The link-layer source is the same, but this isn't used in multicast

hmm... if this is the way it works, then what I said in my email does not 
apply.. !
	one needs to take care that the vif used in Y is not used to 
forward packets, otherwise Z and Y will forward the packets, and wierd 
things will happen.
	It seems this is an implementation issue for virtual lans, and 
not sure we should address it in the spec. !

Regs,
-A

---

From: Shahzad Ali <[email-masked]>
Date: Mon, 21 Dec 1998 18:16:32 -0500 (EST)

Hi,

> not sure we should address it in the spec. !

I think you missed an email somewhere.  In this case, Y is not going to
forward the packets to X.  Y figures out that the incoming interface and
the oif are the same "physical" interface and thus avoids forwarding on
that interface.  So, X receives packets from Z directly.  The entry at Y
is needed to propogate the join prunes to Z so that (*,G) state is
maintained at Z.

-Shahzad