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

[John Zwiebel <jzwiebel at cisco.com>]

On Jul 11, 2006, at 9:09 AM, Ilya Varlashkin wrote:

> > -----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.

It was a rhetorical question.  ie, 'nothing wrong' is happening,
there's nothing to fix.

> > 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.

There are a number of people who would strongly disagree with you
WRT the duplicate packets.  I have no opinion.

> 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.

> > 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

> 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.

It would be rather hard to do this because this only happens on the
last hop router or a stub network.

> > > 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.

Again, you miss my point.  If a router were to assert on the RPF
interface (which it doesn't because that's already in the spec)
it would lose.  I said "-if-"  Perhaps if I had said "_IF_"?
And only to point out that it doesn't matter.

> 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.


> <snip>
>
> 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?

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.
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 last-call (I think) and
I'm fairly certain that the change isn't going to happen.

I don't view this situation as a problem.

> Regards,
> iLya

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