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

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

> -----Original Message-----
> > 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.
> 
> There are a number of people who would strongly disagree with 
> you WRT the duplicate packets.  I have no opinion.
> 

So in trade-off between few seconds dupes versus multiple hours of a
Mbps stream (e.g. TV over IP) flowing over inferior path wasting
resources, keeping customers unhappy and potentially diminishing
investment put into higher-speed links, few seconds are more important?
If you have large subscribers base (think few millions) watching several
TV channels over IP, chances are that most of the time at least one
receiver is present for given group, so MRIB is pretty stable. This is
not some doctored scenario, but quite real. Situation with packet dupes
happens anyway if active link fails and later recovers. If receivers can
cope with that situation, it's strange that they'd get upset during the
initial setup of the session. 

As you say that you're neutral on this issue, it would be interesting to
hear from those who prefer permanet suboptimum use of the network
resources to few seconds convergence period, during which some dupes
occur.
 
> > 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.
> 
> This is a large change to the protocol.  Deploying the change 
> could be problematic.
> 

Assert mechanism as such is already present in existing implementation.
A router implementing proposed changes can coexist with current
implementations because one of two cases happens:

1) if router with new implementation is DR, then router with legacy
implementation will sit quietly like it would have done before. Network
is still performing as with legacy implementation, but upgrade of the
routers can be done step by step without distrupting traffic.

2) if router with new implementation is not DR, then it can send Assert
anyway legacy router will reply just like it would have done seeing
Assert message from legacy implementation. Like in case (1), the upgrade
of the routers can be done step by step without service interruption.

Both of these cases can apply to last-hop routers as well as to routers
on a transit multi-access network.

On the other hand, PIM-BIDIR already has similar thing in form of DF. Of
course it's possible to solve optimum path problem by using PIM-BIDIR
instead of PIM-SM and placing RP very close to the source, but this
doesn't scale well and overall feels like fifth wheel for a car - it
works but it could work without. And if vendors already implement
PIM-BIDIR, then general idea is not completely new to the development
team.

> >> 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,
> Your diagram shows a ospf cost of 65535
> 
I ment that besides that cost of FE0/0 on CE2, all other OSPF settings
are default. So the only reason why CE2 doesn't use VLAN501 as RPF to
the RP or the source is because VLAN501 belongs to non-backbone area,
hence FE0/0 is preferred as backbone interface (sorry didn't explicitly
specify it on the diagram, but all links where OSPF area is not
mentioned are in backbone area).

> It would be rather hard to do this because this only happens 
> on the last hop router or a stub network.
> 
Original problem is still true for transit multi-access network if its
DR happen to be BGP router peering with another AS and using 'nearest
exit' routing. So the proposal address not only last-hop or stub network
but transit networks as well. Besides case with BGP there are also cases
where same problem exist for transit networks running some IGP, but
where PIM DR and PIM non-DR have completely different path to the RP or
to the source with DR's path being non-optimum.

> > Turnaround problem doesn't seem to be in conflict with
> I suggest you look more closely at what happens on a 
> turnaround router and why such a thing is necessary.  The RP 
> has received (S,G,R) prunes so is not joined toward the source.
> 
Indeed, but turnaround router has sent proxy-join in that case so no
conflict. I completely agree with you that asserts on RPF interface
would be disastorous.

> You need the DR to initiate the joins.  If you had 8 routers 
> on the LAN, you wouldn't want them all to join.  And you 
> certainly don't want them all to register.
> 
> The delay is unacceptable.  The potential for screwing up is high.

Original idea behind DR is clear and in its time was good solution, but
case with PIM-BIDIR shows that DF is actually a better choice for
delivering multicast traffic.

> If you would like to write a draft on your proposal and 
> submit it to the PIM-WG, go ahead.  The current RFC is in 

My current experience is probably inadequate to take on such task as
working out complete draft alone. Besides, lacking programming skills I
could only do theoretical side without possibility to provide reference
implementation and test it. If somebody would volunteer to cooperate,
that would be nice.

> last-call (I think) and I'm fairly certain that the change 
> isn't going to happen.
> 
It was not my intention to put up a show stopper to current process in
place. Rather suggestion for further improvement to the protocol as PIM
development would certainly go on even after current draft advances to
proposed standard status. And doing this is not for the sake of doing
this as such, but because I'd like to see PIM running more efficiently
on our network, which spans significant geographical area.

Regards,
iLya

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