Re: [Bier] Comment on BIER-TE

[Toerless Eckert <[e-mail]>]

On Tue, Aug 08, 2017 at 08:49:44PM +0200, IJsbrand Wijnands wrote:
> If traffic engineering on a bigger scale is needed, it may not be required to do it on a per flow basis but rather on a topology. This can be done with normal BIER and different topologies (sub-domains) created BIFT???s. Maybe this is similar to what Greg Mirsky was saying on the other thread, but I don???t think we would run BIER over RSVP-TE. We run it over different topologies.

Right. I left that out of my reply to GregM because he did not
list that option, but i agee that this is a good option in the playbook.

The problem when you do create alternatives paths by using
multiple topologies of an IGP (like ISIS or OSPF) is that
it very much depends on your goals how many topologies you need:

My favourite topic is live-live redundancy, and depending on
topology and where sources and receivers are, this can be
very simple (2 topologies) or very difficult (2 topologies per
set of sources). And of course the latter is a really unnecessary
overhead and in the past operators where alrady weary having
to deal with just two topologies due to the need to consider
two set of per-link metrics. Effectively you're using a very
flexible tool (topologies) to solve a specialized problem.

In general i recommend to instead use MRT (RFC7811) for live-live.
It would be similarily useable with BIER (or any other multicast,
mLDP, PIM for that matter). And it would forego the need to
come up and provision multiple set of metrics. Note that
protocols like ISIS and OSPF may also start to include MTR,
eg: RFC7813, so it becomes more and more confusing to sift through
the options ;-)

Now if you want to use traffic-engineering ("path engineering")
to do steiner trees, IGP topologies will not help. If you want
to do N-path load-splitting, you need N topologies, etc. pp.
"Your mileage will vary" ;-)

Cheers
    Teorless