Re: [Bier] Comment on BIER-TE

[Greg Mirsky <[e-mail]>]

Hi Toerless,
though the goal perhaps was to introduce segment routing paradigm in BIER
architecture, the BIER-TE, in my opinion, does have serious issues when
comparing to a solution that overlays BIER on traffic engineered transport
network constructed using the segment routing with, for example, MPLS data
plane. I'll refer to the latter as multi-layer TEed BIER.
In order to achieve full control over flows, as I understand the proposed
BIER-TE architecture, the BIER-TE domain must be homogeneous, i.e. all
nodes must be BFRs. That would highly likely not allow easy brownfield
deployment as BIER-TE may require new HW. The multi-layer approach will
only require limited upgrade of HW in the domain to add BIER functionality
(assuming that the domain is already using MPLS in its data plane).

If you consider relaxing requirement to use BIER-TE in only homogeneous
domains, then, I believe, you lose control over path selection. Would you
agree?

Regards,
Greg

On Wed, Aug 9, 2017 at 2:18 PM, Toerless Eckert <[e-mail]> wrote:

> Greg:
>
> I think that the use-cases for BIER-TE are pretty clear:
> It is at least the same ones as the ones SR has for steering traffic,
> just for multicast traffic. On top of it, it also allows easy
> controller define live-live multicast without having to bring in
> complex new routing protocol like MRT into the network (live-live
> is rarely a unicast requirement, so this is where multicast
> requirements will be more than typical unicast).
>
> The goals of the designs are also clear: It is designed to provide an
> evolution from RSVP-TE/P2MP for multicast with the same goals as the
> evolution from RSVP-TE/P2P to SR. Aka: like SR for unicast, it provides
> for multicast traffic engineering in a comparable lightweight
> signaling and state fashion as SR using the principle concepts of
> BIER and expanding its architecture.
>
> Of coure, SR is now a more inclusive framework also supporting other
> functions, but i am not relating to those.
>
> If any of this is not clear enough to you from the current draft
> text, i am happy to improve this according to above text or more
> detailed. Pls. let me know.
>
> Cheers
>     Toerless
>
>
> On Wed, Aug 09, 2017 at 12:29:15PM -0700, Greg Mirsky wrote:
> > Hi Toerless, Ice, et. al,
> > I think that we arrived to realization that it may be helpful first to
> > formulate the problem, requirements towards TE at BIER layer, if any.
> >
> > Ice,
> > we may have slightly different terminology in using 'topology', but
> you've
> > captured my message - traffic engineering, as well as protection, may be
> > better achieved in BIER's underlay, i.e. transport network. And segment
> > routing with MPLS dataplane may fit the bill. Whether one uses
> distributed
> > control plane or central controller, e.g. PCE - secondary issue.
> >
> > Regards,
> > Greg
> >
> > On Wed, Aug 9, 2017 at 11:51 AM, IJsbrand Wijnands <[e-mail]>
> wrote:
> >
> > > Toerless,
> > >
> > > > 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" ;-)
> > >
> > > https://en.wikipedia.org/wiki/Wikipedia:Solutions_looking_fo
> r_a_problem
> > >
> > > :-)
> > >
> > > Thx,
> > >
> > > Ice.
> > >
> > > _______________________________________________
> > > BIER mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/bier
> > >
>
> --
> ---
> [e-mail]
>