Subject: [pim] BIDIR PIM load balancing

From: Isidor Kouvelas <[email-masked]>
Date: Mon, 21 Jul 2003 18:33:04 -0700

IMPORTANT: Following discusses a change in the bidir protocol that is
possibly incompatible with implementations of the current spec.
Please read if you have a BIDIR PIM implementation.

A Bidir PIM spec update was presented during the Vienna IETF PIM WG
meeting. Slides for the presentation are included below in MGP format.
I am sending this email to solicit opinions on a specific point that
was discussed in Vienna.

The point has to do with DF election load balancing. In the current
Bidir PIM spec (draft-ietf-pim-bidir-05.txt,.ps) the metric comparison
rules used in the DF election do not take into consideration the
Rendezvous Point Address (RPA). As a result, if two RPAs are
configured in a network to serve different group ranges and both these
RPAs are on the same subnet, then the shared trees for the two RPAs
will be identical. This will happen because on each subnet in the
domain the same upstream router (towards the RPA link) will be elected
as the DF for both RPAs.

In order to introduce the possibility of load balancing in bidir and
allow the distribution trees for different RPAs with the same RPL to
diverge, the DF election metric comparison mechanism must be modified
to take the RPA into consideration. Instead of simply comparing
metrics and tie-breaking using the advertising router IP address, the
comparison must use as a tie-breaker a hash calculated using both the
advertising router IP address AND the Rendezvous Point Address (RPA).

In the Vienna meeting it was agreed that such functionality makes
sense to add to the spec. However, if this functionality is added to
the spec without requiring negotiation through a hello option then it
introduces an incopatibility with existing implementations. If a
router that takes into consideration the RPA address is present on a
link with an older router that does not and there is a tie in the
metrics to reach the RPA, then the two routers may both think they
should win the DF election and therefore the election will never
converge with a winner (thus preventing tree creation and data
propagation).

At this point the members of the WG present in Vienna were asked
whether introducing such an incompatibility at this stage was
acceptable or if instead we should create a new hello option to
negotiate the use of the RPA in the DF election metric comarison.
Everyone present seemed to agree that the hello option is not
necessary and that we can simply make the incompatible change.

I am sending this email to the list to make sure that there are no
members that were not present in Vienna that have a problem with this
decision.

thanks
Isidor

%include "/usr/home/kouvelas/lib/default.mgp"
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page
%nodefault
%size 8, font "roman", fore "white", vgap 20
%back "blue"

%center

Bidir PIM update

%size 5, font "roman", fore "white", vgap 20
draft-ietf-pim-bidir-05

%size 4
Mark Handley
Isidor Kouvelas
Tony Speakman
Lorenzo Vicisano

%page

Summary of Changes

Changes from draft-04 to draft-05:
	Rendezvous Point (RP) replaced by Rendezvous Point Address (RPA) and Rendezvous Point Link (RPL).
	Clarified that infinite metric (worse possible metric) MUST be used in DF election messages on RPF interface.
	Received PIM Joins targeted at non-DF routers are now stored by the target to improve convergence speed. ONLY the DF may forward traffic downstream. A non-DF receiving a join may only start forwarding after winning the election.
	Expanded DF election event description.
	Added security considerations section.

Possible future mods:
	DF election load balancing through RPA hashing.
	No BSR hashing for Bidir?

%page

RPA and RPL replace RP

	The RP in bidir PIM does not need to be an actual router as there are no special RP functions to perform.
	In the previous draft the DF election did not work on the link containing the RP address (non-RP could win IP address comparison).
	Fixed by replacing the concept of a Rendezvous Point with that of the Rendezvous Point Address (RPA) and a Rendezvous Point Link (RPL) (link containing RPA).
	Specified that DF election does not take place on RPL.
	If RPA belongs to a real router then that router has no special function and MUST still forward traffic upstream onto the RPL.

%page

DF Election Load Balancing 

	DF election determines RPF neighbour to reach RPA on MRIB indicated RPF interface.
	Two or more upstream routers may have equal cost paths to the RPA.
	Per-group load balancing (as with Sparse-Mode PIM) is not possible.
	It is possible to configure multiple (two or more) RPAs on the same link and influence tree construction for each RPA.
	Instead of tie-breaking the DF election using the IP address of the router advertising the metric, a hash combining the router IP address and the RPA can be used.
	Is this useful? If so then do we care about backward compatibility with current implementations (i.e. need a hello option to negotiate hashing).

%page

No BSR hashing for Bidir

	Upstream forwarding in bidir can be achieved without any data driven events or group specific state.
	This requires a (*,G/mask) forwarding entry.
	To implement BSR hashing forwarding engine must be aware of hash function as well as the RP addresses.
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim