Subject: Few questions

From: "pnh" <[email-masked]>
Date: 28 Jun 2001 06:18:48 -0000

Hello,
    I have few doubts in latest PIM-SM draft (draft-ietf-pim-sm-v2-new-02.ps).
1. <s,g> join and <s,g,rpt> join on same interface is allowed? Spec doesn't seems to be talking about how to handle this? If there is a downstream <s,g> state why do we need to maintain downstream <s,g,rpt> state? I guess one should ignore <s,g,rpt> prune on a interface if <s,g> is already present.
2. Why is JoinDesired(S,G) dependent on KeepAlive timer and not just on immediate_olist(S,G)?

Thanks for your time.

pnh

____________________________________________________
Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm

---

From: John Zwiebel <[email-masked]>
Date: Thu, 28 Jun 2001 10:49:07 -0700

pnh wrote:
> 1. <s,g> join and <s,g,rpt> join on same interface is allowed? Spec doesn't seems >to be talking about how to handle this? If there is a downstream <s,g> state why do >we need to maintain downstream <s,g,rpt> state? I guess one should ignore <s,g,rpt> >prune on a interface if <s,g> is already present.

I can read your question many ways, but I'm going to assume that you are
asking why a router might need to receive an (S,G)JOIN _and_ and
(S,G,RPT)PRUNE
on the same interface and how you are suppose to handle this.

In a steady state situation you are correct that you can ignore the
(S,G,RPT)PRUNE.
But remember that what you have here is a situation where the
shared-tree and
the source-tree overlap so you must maintain information for both trees.

What happens if the receiver on the source-tree goes away and you don't 
separately track the receipt of (S,G,RPT)PRUNEs?  (S,G) state is deleted
and now you have only (*,G) state which is propagated up the share-tree
to
the RP which may then have to trigger an (S,G) join toward the source to
rebuild the "X-line" (what I call the shortest-path from the source to
the
RP -- which is just part of the source tree but which has some special
requirements and isn't identified by any other term so I call it the
"X-line"
so I don't have to say "the shortest path from the source to the RP").

Now data flows up the X-line to the RP and down the shared-tree for up
to
60 seconds when the router we are talking about receives a
(S,G,RPT)PRUNE
and creates (S,G,RPT) state to then prune off all the traffic that we
just
asked for.

If you think of the three separate ways traffic can be delivered:
  -- shared-tree
  -- source-tree
  -- X-line (which is required to deliver traffic down the shared-tree)

and remember that you have to keep information for each of these because
they may arbitrarily overlap or intersect with one another at almost
any point in your network.  And remember that any of these can change at
any time as new receivers come up, the source goes away and/or the RP
changes.  Then you have a better possibility of meeting all your
requirements
for sparse-mode.

> 2. Why is JoinDesired(S,G) dependent on KeepAlive timer and not just on immediate_olist(S,G)?

I'm assuming you are referring to this macro:

	bool JoinDesired(S,G) {
	  return( immediate_olist(S,G) != NULL
	  OR ( KeepaliveTimer(S,G) is running
	    AND inherited_olist(S,G) != NULL ) )
	}

The immediate_olist can be non-NULL if you receive either an (S,G) JOIN
_or_ an IGMPv3 host report that specifically lists "S".  

The second applies to a "last-hop" router.  If that router is serving
hosts
that only run IGMPv2 then the "inherited_olist" is non-NULL because the
receiver can only ask for (*,G).

If the source stops sending, but the receiver keeps sending (*,G) IGMP
host reports, the keepaliveTimer is required to know when to delete the
(S,G) from the last-hop so you can tear down that shortest-path. 
Otherwise
that path will be up as long as the receiver continues to send (*,G)
IGMP
host reports.

NOTE that with SSM and IGMPv3 the receiver sends (S,G)host reports so 
the last-hop router doesn't have to track the keepAliveTimer because now
we "assume" that the host knows more about what sources are sending than
the router knows.  In this case, the (S,G) will stay alive "forever" (or
until the host stops asking for it) but this is what we want to have 
happen.

> _______________________________________________
> Pim-external mailing list
> [email-masked]
> http://mailist.procket.com/mailman/listinfo/pim-external

---

From: Pawan <[email-masked]>
Date: Fri, 29 Jun 2001 14:42:29 +0530

John,

Thanks for explaining things in detail. Please see my inline comments.

>and creates (S,G,RPT) state to then prune off all the traffic that we

Thanks for in-depth info. Now I understand that why one needs to maintain 
both states with current spec as (S,G,rpt) prune is not triggered while 
already in pruned state.

>receiver can only ask for (*,G).

As KeepaliveTimer(S,G) will be running even at in-between routers, 
JoinDesired(S,G)
will maintain <s,g> state even at those upstream routers, even if no 
downstream router is interested
in (S,G) explicitly, i.e. even if all downstream (S,G) states are timed 
out, we will continue to maintain
(S,G) state! Shouldn't we be doing this only at last hop router?

Thanks

pnh

---

From: John Zwiebel <[email-masked]>
Date: Fri, 29 Jun 2001 09:44:50 -0700

> (S,G) state! Shouldn't we be doing this only at last hop router?

There is a difference of opinion here.  IHNO (I have no opinion).  I'll
try to outline both sides of the issue.

One point is that if the last hop deletes all its outgoing interfaces,
then
it will trigger a PRUNE toward the source removing the interfaces from
the
Olist of the upstream routers.  If its the last interface in the olist
then
those routers won't forward traffic and so the KeepaliveTimer won't be
updated.
(ie JoinDesired(S,G) will go to false).

Since this part of the protocol seems to be working, (S,G) state is
removed
from the SPT, perhaps it doesn't pay to change it.

OTOH, the intermediate routers do have to update (S,G)KeepaliveTimer and
this
may be an expensive process.  ("expensive" is in the eye of the beholder
-- IHNO).
And for the intermediate routers the KeepaliveTimer(S,G) doesn't "do"
anything.
[And if you are talking about an SSM session that timer doesn't "do"
anything
anywhere along the SPT]

OTOOH, when you are trying to debug a network problem and you want to
know if
the traffic is flowing or not, being able to look at the mroute and see
that
the (S,G) expire time is never less than 2:59 tells you that this router
is
forwarding a steady stream of multicast traffic.  So, for a human, this
timer
is very useful.  (Of course, in this case, the timer is just telling you
when
the last packet went by and isn't doing anything WRT the protocol).

---

From: Isidor Kouvelas <[email-masked]>
Date: Fri, 29 Jun 2001 09:30:27 -0700

>(S,G) state! Shouldn't we be doing this only at last hop router?

The issue is that it is impossible to distinguish a turnaround router
from one where the shared and shortest path trees just cross. Hence,
once the SPT has been set up in an intermediate router you may create
intermediate outages for downstream receivers whose DR is configured
with "spt-threshold infinity" if you stop joining the (S,G) while the
source is still active.

thanks
I

---

From: Pawan <[email-masked]>
Date: Fri, 29 Jun 2001 23:04:55 +0530

Thanks Isidor,

But I'm not clear why should there be any outages in downstream, provided
router switching from RPT to SPT takes care of sending (S,G,rpt) Join towards
RP and when first data packet is received on RPT, send prune towards SPT.
But yes, it will be very difficult to achieve so if both SPT and RPT is 
through same
LAN!
My main concern is regarding the unnecessary (S,G) states at all upstream 
router
even when nobody downstream is actually interested in (S,G) specifically.

Thanks
Pawan

---

From: John Zwiebel <[email-masked]>
Date: Fri, 29 Jun 2001 10:34:52 -0700

Isidor Kouvelas wrote:
> from one where the shared and shortest path trees just cross. 

I don't believe this statement is true otherwise you'd have to always
have a turnaround router when these two paths cross.  You know its a
"turnaround router" when you receive a JOIN/PRUNE message that has only
a (*,G) part and no (S,G) part (prune or join).  So, I think what you
mean is that unless you specifically record this information and mark
the router as being in this state, you won't know that its a turnaround
router.

So, I'm assuming that what you (Isidor) mean here is that unless you
mark the (S,G)
entry as a "turnaround" entry, then it is indeed impossible to know this
from
just looking at the information in the mroute.

Let me expand on what Isidor is saying...

FWIW: 
   A "turnaround" router prevents data flowing all the way to the RP
   when a member (last-hop router) wants to remain on the shared-tree. 
The 
   new spec doesn't address this completely.  Whether or not you want to 
   implement this capability is debatable.  On the plus side, you save
network
   bandwidth as data isn't constantly forwarded to the RP.  On the
negitive side,
   well, it isn't necessarily "easy" to implement.  Also, it isn't clear
yet 
   how often a network will be configured so that some receivers will
stay on
   the shared-tree and some will switch to the shortest path.  

   But the advantages are also dependent on the physical layout of your
network.
   If your RP is on the edge, it will initially join toward the source
(one
   branch in the SPT which I've called the X-line) so now you have a
shortest
   tree branch.  Even if _all_ your receivers are configured to remain
on the
   shared-tree you may still have the X-line intercept a shared-tree
branch
   a long way (in hops) from the RP.

   Now, if your source is spewing out tons of traffic and your RP is at
the
   end of a fairly skinny pipe, you have problems.  (One of them being
you've
   designed your network poorly, but that's another problem.)

> Hence,

(FWIW, turnaround routers only exist where the shortest-path from the
source to the RP intersects with a shared-tree branch.  Cisco uses a X
to mark such routers.  Hence, I call it the X-line.)

The spec (S,G) keepalive timer is only updated when traffic is forwarded 
by the router.  The "classic" turnaround router has an (S,G) with a NULL
olist and therefore must update the Keepalive timer when it "sees"
traffic
on the RPF interface toward the source.

Note that as long as the RP _knows_ there are receivers on the
shared-tree
only (ie it is receiving (*,G) joins without an (S,G) part) it is
responsible
for pulling source traffic all the way to the RP.  The turnaround router
moves this functionality to the first point (points since there can be
many share-tree branches) where the shared-tree-branch and X-line
overlap.

Now, isn't this a lot more than you wanted to know?  The spec only
mentions
the turnaround router in passing.  Here I do have an opinion that a
turnaround router is a "good thing".  I admit though that the changes in
the way multicast traffic is forwarded may make it obsolete.  (or
perhaps
in the way PIM-SM is used in a given network make it unnecessary.)

---

From: John Zwiebel <[email-masked]>
Date: Fri, 29 Jun 2001 10:43:14 -0700

> router switching from RPT to SPT takes care of sending (S,G,rpt) Join towards

Did you mean "Prune"?  (S,G,R)JOINs are very rare and only used to
override
a prune when you've had a "strange" topology that causes the upstream
routers
assert for who the forwarder is.

> even when nobody downstream is actually interested in (S,G) specifically.

This doesn't happen.

---

From: Isidor Kouvelas <[email-masked]>
Date: Fri, 29 Jun 2001 11:11:57 -0700

Pawan writes:
>through same LAN!

You are right. But this behaviour is not defined in the spec...

>My main concern is regarding the unnecessary (S,G) states at all upstream router

The main point is that intermediate routers should not *create* (S,G) state.
If soneone initially requests (S,G) state I do not think it is a real problem
keeping it around till the source stops sending or the receivers leave.

thanks
I

---

From: Pawan <[email-masked]>
Date: Fri, 29 Jun 2001 23:56:16 +0530

John,
    No I meant (S,G,rpt) Join towards RPT, since it had previously sent 
(S,G,rpt) Prune towards RPT when (S,G) state was established.

Consider following scenario.

       RPT           SPT
        |             |
        |             |
      +----+        +----+
      | T4 |        | T5 |
      +----+        +----+
          \          /
           \        /
            \      /
             +----+
         +---| T1 |---+
        /    +----+    \
       /                \
      /                  \
   +----+              +----+
   | T2 |              | T3 |
   +----+              +----+
     |                   |
     R1                 R2

R1 sends (S,G) Join and R2 send  (*,G) Join.

There will be (*,G) state at T1, T3 and T4 and (S,G) state at T1, T2 and T5.
Besides T4 hold (S,G,rpt) Prune state.

Now at some later point of time, R1 disappears which will make T2 to send 
(S,G) prune towards T1. Now no (S,G) state at T2.
and nobody downstream of T1 is specifically interested in (S,G)  (R2 is 
interested in *,G ).
But because of keepalive timer T1 can never switch back! and everyone holds 
what ever state they are holding as long as Keepalive timer keeps ticking 
at T1.

To correct this (I mean to release the resources), T1 could have sent 
(S,G,rpt) Join towards T4 and once packet is received on (*,G) send (S,G) 
prune towards T5. I understand the issue if both T4 and T5 are no same LAN. 
I guess one can either go for duplicate packets for some time or a data 
flow break for some time.

Thanks
Pawan