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

Prashant Jhingran <prashantj@huawei.com> Tue, 11 July 2006 11:54 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0GpP-0001aE-Id; Tue, 11 Jul 2006 07:54:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0GpO-0001ZH-8c for pim@ietf.org; Tue, 11 Jul 2006 07:54:58 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0FsU-00037H-75 for pim@ietf.org; Tue, 11 Jul 2006 06:54:06 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0FW7-0002C8-RZ for pim@ietf.org; Tue, 11 Jul 2006 06:31:07 -0400
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2800J6FIYBA0@szxga03-in.huawei.com> for pim@ietf.org; Tue, 11 Jul 2006 18:39:47 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J280003BIYBQT@szxga03-in.huawei.com> for pim@ietf.org; Tue, 11 Jul 2006 18:39:47 +0800 (CST)
Received: from b70625 ([10.70.149.86]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J28002PDIM0TW@szxml03-in.huawei.com> for pim@ietf.org; Tue, 11 Jul 2006 18:32:27 +0800 (CST)
Date: Tue, 11 Jul 2006 18:30:06 +0800
From: Prashant Jhingran <prashantj@huawei.com>
Subject: RE: [pim] pim-sm DR, assertion and optimum traffic flow
In-reply-to: <1ECE1A8A87013C45B408409749737C300110F682@paul.adoffice.local.de.easynet.net>
To: pim@ietf.org
Message-id: <000001c6a4d4$fa7d3750$5695460a@china.huawei.com>
Organization: Huawei
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
X-Mailer: Microsoft Outlook, Build 10.0.3416
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: -2.6 (--)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc:
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: prashantj@huawei.com
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

Hi,

This would cause chaos in the network since it will make pim-sm behavior
quite unpredictable. You may visualise this by considering CE11-FE2
disconnected to vlan-501 and thus assert happening on Vlan-400 between
CE11 and XR2 when CE2 requests packets from RP.

If there exists a back door link (like in your topology) then I feel
that admin should configure a higher DR priority on the router connected
via backdoor link (viz. CE11) so that probability of having sub-optimal
path is minimized.

Regards,
Prashant

-----Original Message-----
From: Ilya Varlashkin [mailto:Ilya.Varlashkin@de.easynet.net] 
Sent: Tuesday, July 11, 2006 12:50 AM
To: pim@ietf.org
Subject: [pim] pim-sm DR, assertion and optimum traffic flow


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



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