RE: [pim] pim-sm DR, assertion and optimum traffic flow

["Ilya Varlashkin" <Ilya.Varlashkin at de.easynet.net>]

> -----Original Message-----
> On Jul 10, 2006, at 12:49 PM, Ilya Varlashkin wrote:
> 
> >  Is there some reason of not doing so?
> >
> 
> In the initial case when traffic is flowing via CE2 is there 
> duplicate traffic?  Is traffic flowing to the receivers who want it?
> 
In the initial case (prior link failure on CE2) there is no duplicate
traffic since CE11 is configured and operating properly (so it didn't
send PIM-Join, and its o_list for the group is empty). The only receiver
of interest in this test is XH0.

> Yes, it could be "fixed", but there's no benefit and a 
> significant cost because you are proposing interrupting the 
> data flow or causing duplicate packets to XH0.
> 
Minute dupes on the high speed LAN sounds still better than delivering
mcast traffic over worser-metric interface since that either reduces
performance (e.g. delay on multi-hop E3 path to RP, when better path is
over direct STM-1 or gigabit ethernet) or unnecessary loads transit
routers on the backup path, while they have more important things to do
than to carry mcast traffic without good reason. So benefit is
definetely there. 

Going a bit more into details of proposed implementation, it could be
for example that Assert-Loser should stop sending traffic not
immediately after assert with better metric received, but either after
first packet heard that Assert-Loser didn't send or alternatively some
'Shutup' message can be sent by Assert-Winner when it starts sending
packets to the LAN (slightly similar to RP sending Register-Stop after
joining SPT to the source). I believe we could work out feasible
solution, I for one would be willing to contribute as much as I can
either in details of the proposed mechanism or/and testing
implementation in our lab.

> In "most" cases like this when the upstream metric gets too 
> high, the DR would end up RPFing through vlan 501.  So CE2 
> would have sent the join through
> CE11 and your problem would be solved.
> 
> I'm curious how you got CE2 to still think vlan400 was the 
> RPF interface when you put such a high cost on it.  You must 
> have put some high OSPF costs on that interface too.
> 

No I didn't put high cost, the important part is that VLAN501 is OSPF
area 1, while VLAN 400 is OSPF backbone area zero (it's quite real-world
scenario). I could even extend this test to inter-AS multicast (so
VLAN501 would be in fact one AS while source is in another AS), but then
main problem would be too much burried into details of all the extra
features needed for that. So CE2 prefers path over backbone for
inter-area traffic, that's where RP is.

> > Routers must never do assert
> > on the incoming interface (RPF interface), else they'll cut 
> themselves 
> > from the traffic (since traffic is allowed to arrive only RPF 
> > interface, all other must be dropped).
> 
> FWIW, -if- a router were to assert on its RPF interface 
> (remember you only assert on the olist, but some 
> implementations put the RPF interface into the olist to solve 
> the 'turnaround' problem') it should be rather difficult for 
> it to win that assert because that would indicate it has a 
> better metric to the source/RP than the other routers its 
> asserting with.
> 
That's why I said that assert to be performed only non _non_ RPF
interfaces. Turnaround problem doesn't seem to be in conflict with
proposed assert behaviour since turnaround router (when it figures out
that it's actually turnaround router) will have its RPF interface for
the source pointing to the right direction and assert will not be
performed there. Should traffic not switch to SPT and keep staying on
the shared tree, turnaround router will still have (S,G) entry in MRIB
because RP has joined SPT to towards the source. The main difference of
the proposed change to the condition is that interface list would also
include interfaces for which given router is not currently delivering
traffic, although it could.

Re-phrasing proposed changes from the router prospective could be as
"hey, I see you get traffic here for this group. I don't do it now, but
actually I could do it better".

Moreover, if 'assert' works as proposed, then it's actually possible to
get rid of the DR altogether - instead of DR sending PIM-join
immediately upon receiving IGMP-join the routers on common subnet could
run dynamic election of designated forwarder for given (*,G) or (S,G).
This would result in slightly added join delay, but this can be as
little as 1-2 second (should be big enough for routers to come to an
agreement and still small enough for human or non-interactive
application to worry about compare to the benefit of later run-time
traffic performance).

What do you think?

Regards,
iLya


_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim