Re: [Bier] Comment on BIER-TE

[Toerless Eckert <[e-mail]>]

Inline.

On Wed, Aug 09, 2017 at 07:43:05PM -0700, Greg Mirsky wrote:
> 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.

Do you have pointers to any document describing that solution approach
or would you mind to elaborate on it ? I asked the first time around and
provided explanations about the insufficiency of various approaches
and you did not answer to that first request for references or commonted
on my proposed interpretation of your claims.

> 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).

| 4.8.2.  Supporting nodes without BIER-TE
| 
|    Routed adjacencies also enable incremental deployment of BIER-TE.
|    Only the nodes through which BIER-TE traffic needs to be steered -
|    with or without replication - need to support BIER-TE.  Where they
|    are not directly connected to each other, forward_routed adjacencies
|    are used to pass over non BIER-TE enabled nodes.
| 
| 8.  BIER-TE and Segment Routing
| 
|    Segment Routing aims to achieve lightweight path engineering via
|    loose source routing.  Compared for example to RSVP-TE, it does not
|    require per-path signaling to each of these hops.
| 
|    BIER-TE is supports the same design philosophy for multicast.  Like
|    in SR, it relies on source-routing - via the definition of a
|    BitString.  Like SR, it only requires to consider the "hops" on which
|    either replication has to happen, or across which the traffic should
|    be steered (even without replication).  Any other hops can be skipped
|    via the use of routed adjacencies.
| 
|    Instead of defining BitPositions for non-replicating hops, it is
|    equally possible to use segment routing encapsulations (eg: MPLS
|    label stacks) for "forward_routed" adjacencies.

Aka: the maximum bit-saving and minimum HW-deployment option is to
only deploy it for nodes where replication is needed.

What the existing text i think misses to discuss yet is to discuss is a bit whether or
how much BIER-TE BFIR and BFER need to supprt, eg: for imposition/disposition,
so that needs to be more detailed (in line with my promise to Alia):

A) On a BFIR, imposition does not mean the need to support full BIER-TE forwarding
  plane semantic. Just the imposition of some opaque header (which later BFRs will see
  to be BIER) and (eg: SR) label to the first replicating BFR. Only that first replicating
  BFR would need to understand the BIER-TE forwarding semantics., the BFIR just does this 
  imposition and sends an MPLS packet.
B) If the BFIR needs to send multiple packets, eg: for different SI or even for the same
  SI, but multiple remote next-hop BFR: IN this case  the forwarding plane
  would just need to be programmed with multiple adjacencies as in A). Aka:
  These adjacencies could simply be part of the IP multicast OIF list.
C) On a BFER, support for BIER-TE forwarding could be avoided if the encap
  would provide some form of BIER-header disposition label. The remote-adjacency
  on the preultimate hop would then simply have the eg: SR label stack that
  not only steers the packet to the BFER, but also includes that disposition label.
  Aka: The BFERs functionaly would just have to be "see this label -> dispose
  of some magic N-byte junk at the start of the packet (BIER header) and pass the rest to
  IP (multicast) routing in VRF xyz"

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

See above. Its really like SR. Only need to support where you need to use it,
and use really means in BIER-TE where you want to replicate.

In the picture i pained for Hu in the SI thread, i was suggesting the example of
a large network with edge areas and a core, interconnected with a few edge routers
each, and yu want to steer traffic maybe across specific combinations of
(ingres-edge-2-core-routerX, core-2-egres-edge-routerY) and replicate in the
receiver edge area also with explicit path selection because it may have
eg: rings (like in MSO networks) where you want to control traffics ring direction).

Hard to suggest the best setups without a specific topology/set of requirements,
but of course i am happy to write down an example.  I was just hoping that examples
of such controller strategies how to allocate bits etc. would be rather a nice
follow up document instead of bloating the architecture doc.

The model of BIER-TE is really very much in spirit also with the fully programmable forwarding
plane directions happening in unicast (SRv6 etc). I hope they're defining
"opaque header imposition/disposition" actions, if not, then i would certainly like to suggest
that if/once BIER-TE was a WG item.

Cheers
    Toerless

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

-- 
---
[e-mail]