Re: [Bier] Comment on BIER-TE

[Greg Mirsky <[e-mail]>]

Hi Toerless,
got busy and couldn't respond in time. Please find my answers, notes
in-lined tagged GIM>>.

Regards,
Greg

On Thu, Aug 10, 2017 at 7:43 AM, Toerless Eckert <[e-mail]> wrote:

> 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
>
GIM>> I don't think that there's need to describe how to construct per BIER
sub-domain BIRTs. And with that one can have traffic engineered sub-domains
of his/her liking. And choosing among them is as simple as choosing which
sub-domain to use for forwarding.

> 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.
>
GIM>> Not with BIER-TE model.

>
> 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"
>
GIM>> If, as you say, "BFER-TE support could be avoided" by using segment
routing in the underlay, then why do we need BIER-TE? You just re-stated my
point, thank you.

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