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

"Ilya Varlashkin" <Ilya.Varlashkin@de.easynet.net> Mon, 10 July 2006 16:49 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzyx7-00077m-78; Mon, 10 Jul 2006 12:49:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzyx5-00077e-EN for pim@ietf.org; Mon, 10 Jul 2006 12:49:43 -0400
Received: from softy.ision.net ([194.163.250.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzyx3-0003YA-2x for pim@ietf.org; Mon, 10 Jul 2006 12:49:43 -0400
Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1Fzyx1-0003iB-QP for pim@ietf.org; Mon, 10 Jul 2006 18:49:39 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 10 Jul 2006 18:49:38 +0200
Message-ID: <1ECE1A8A87013C45B408409749737C300110F682@paul.adoffice.local.de.easynet.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: pim-sm DR, assertion and optimum traffic flow
Thread-Index: AcakQNSxxkbxkh8WSSuDnZXRV5iaRg==
From: Ilya Varlashkin <Ilya.Varlashkin@de.easynet.net>
To: pim@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Subject: [pim] pim-sm DR, assertion and optimum traffic flow
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
Errors-To: pim-bounces@ietf.org

Hello,

I'm new to this list and couldn't find this issue in the archives, sorry
if it was already discussed.

Just went through draft-ietf-pim-sm-v2-new-12.txt and found that there
seems to be same old problem as in current RFC2362: on multi-access
network elected DR may have inferior metric towards RP or towards a
source (depending whether shared- or source-tree is being currently
used), yet a router with better metric will never send 'Assert' as long
as DR's path towards RP or the source stays stable. I've reproduced this
in the lab and actual router behaviour confirms this. To make
explaination a bit more clear, have a look at the test network setup
here: http://citadel.nobulus.com/~ilya/mcast-dr-study.pdf

In that setup router CE2 is elected DR on VLAN501 only due to its
address, priority is the same as of CE11. When receiver XH0 joins a
group (I've used 239.0.1.1), CE11 sits quietly and only CE2 sends
PIM-Join towards router XR2 (RP). So far so good. Now host XH3 starts
sending to the group, traffic naturally goes via RP and then via CE2 to
VLAN501 where it's finally received by XH0. Obviously traffic is
delivered via suboptimum path, however CE11 doesn't do anything to
improve situation (since interface towards VLAN501 is not in o_list for
the group). This is all expected.

Now, CE2's uplink towards RP fails (assume routers are configured not to
switch to SPT, but similar behaviour can also be observed in that case
too). CE2 sends new PIM-Join, this time it goes via VLAN501 and via
CE11. Traffic starts flowing via CE11. Now CE2's uplink towards RP
recovers, CE2 sends new PIM-Join and traffic starts flowing via CE2. For
some while however CE11 still has (*, 239.0.1.1) entry in MRIB, so it
keeps forwarding traffic to VLAN501, packet duplication is in place. Now
both CE2 and CE11 see each other traffic, and both have interface
towards VLAN501 in o_list for (*,239.0.1.1). Condition
CouldAssert(S,G,I) becomes true, so assert process begins and CE11 comes
as the winner. Traffic now flows over optimum path, even while all links
are up.

It's clear that this behaviour is per specification, but wouldn't it be
better if CE2 and CE11 could agree on who's forwarding on VLAN501
without having CE2 uplink to fail? One possible solution for this could
be to change assert condition so that it checks not traffic present on
an interface in o_list, but instead it kicks assert process as soon as
traffic is heard on any interface with active PIM-neighbor as long as
this interface is not incoming interface. In terms of described test
setup, assert would kick in as soon as CE2 detects traffic on any
interface other than FE0 (in case we switch from shared-tree to SPT,
this will be 'anything but FE1'). Is there some reason of not doing so?

Kind regards,
iLya (IV21-RIPE)

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