Subject: RE: mboned: draft-lehtonen-mboned-dynssm-req

From: "James Lingard" <[email-masked]>
Date: Mon, 27 Jun 2005 14:02:40 +0100

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Stig Venaas
Sent: 22 June 2005 12:02
To: Hoerdt Mickael
Cc: [email-masked]
Subject: Re: mboned: draft-lehtonen-mboned-dynssm-req

On Fri, Jun 10, 2005 at 07:40:21PM +0200, Hoerdt Mickael wrote:
[...]
> Related to this, there is something not clear for me : a PIM-RP is there
> for source
> discovery inside an ASM/IP session. What happen if a new receiver join
> the session and that all other DR's switched to the SPT. when the RP
> receive the (*,G) join coming from the new receiver, will it join all
> the sources in the session again to permit the DR of  the

If you implement just what the spec says, then I believe what happens is
that no register stop is sent next time the DR sends a register, and
hence the RP will start receiving. But this might take up to 65s with
the default values I think.

What I have seen in practise though, is that the RP does join towards
the sources. I think that is reasonable, but I can't see anything in
the PIM spec that states or leads to this behaviour.

[James]
The behavior you say you have observed is a feature of the revised spec (draft-ietf-pim-sm-v2-new-11).  When the RP sends an (S,G) Register-Stop, it starts its (S,G) KeepaliveTimer.  Therefore, when it receives the (*,G) Join, JoinDesired(S,G) becomes TRUE due to the clause "( KeepaliveTimer(S,G) is running AND inherited_olist(S,G) != NULL )".
[/James]

I would also like to know if there is something I have missed, or if
there are differences in behaviour between implementations.

[James]
I don't know what RFC 2362 (the previous version of the spec) says about this, but it may well be different.  And there are certainly many implementations of RFC 2362 out there.
[/James]

If the last-hop routers immediately switch to SPT, then a consequence
of this I suppose is that you get lots of state changes in many routers
over a short time.

The different trees constructed and removed are:

1. RPT from last-hop to RP
2. SPT from RP to first-hop
3. SPT from last-hop to first-hop
4. prune S from RPT
5. prune SPT from RP to first-hop

[James]
This is unfortunate, but I think it's an unavoidable consequence of the flexibility of PIM-SM.
[/James]

A theoretical way of improving this would be to do something like

1. RPT from last-hop to RP
2. RP signals down the RPT who the sources are, but not actual data
	It knows the sources but doesn't receive data from them
	This would be slightly similar to the null-registers...
3. SPT from last-hop to first-hop
4. prune S from RPT

You would avoid building and removing the SPT from RP to first-hop
then.

[James]
That would be a neat optimization but would require that the RP knows that all the last-hops are going to switch to the SPT - otherwise the RP has to re-join the SPT anyway to obtain the traffic for those last-hops that do not make the switch.

It's certainly not the case that all implementations always switch to the SPT at the last-hop.  For example, on Cisco IOS this is configurable using the "ip(v6) pim spt-threshold" command.
[/James]

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/