Re: [Bier] Comment on BIER-TE

[Toerless Eckert <[e-mail]>]

In-line

On Sun, Aug 13, 2017 at 11:40:27AM -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.

I think there is. I am still very much guessing what you are suggesting, and you
did not comment the extensive explanations i provided you in my prior 
answers. If you want to establish static, non-IGP driven BIRT, that should be
written down as a deployment model. Especially if you want to support N
alterntive paths/"trees" through the network. This requires N * BIRT and this
can easily become a lot more aggregate BIRT state in routers than what you
would get with BIER-TE. And how do you udate the state when topology changes
happen. This is all quite non-obvious IMHO.

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

Yes, 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.

Please read what i have written. I have been adressing your prior email
concerns about incremental deployability. The sentence you referred to out
of context said "On a BFER, support for BIER-TE forwarding could be avoided if..."
                 ^^^^^^^^^                                                  ^^^^^

Woth SR, you can avoid supporting/enabling BIER-TE on nodes that only need to steer,
but not replicate. With both SR and BIER-TE, you do not need to change state
in midpoints when you want to change steering/replication. With your proposal
"provisioned BIRT", that would much more likely be necessary.

Does my explanation help to understand how BIER-TE is only required on
the nodes where replication is desired ? If not, then maybe we could
have a higher bandwidth channel to solve the misundertanding. 

Cheers
    Toerless

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

> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier


-- 
---
[e-mail]