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
- RE: [pim] pim-sm DR, assertion and optimum traffi… Ilya Varlashkin
- [pim] pim-sm DR, assertion and optimum traffic fl… Ilya Varlashkin
- RE: [pim] pim-sm DR, assertion and optimum traffi… Ilya Varlashkin
- RE: [pim] pim-sm DR, assertion and optimum traffi… Prashant Jhingran
- Re: [pim] pim-sm DR, assertion and optimum traffi… John Zwiebel
- RE: [pim] pim-sm DR, assertion and optimum traffi… Ilya Varlashkin
- Re: [pim] pim-sm DR, assertion and optimum traffi… John Zwiebel