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