Re: [Bier] Comment on BIER-TE

[Greg Mirsky <[e-mail]>]

Hi Toerless,
thank you for the continued discussion. I hope it is interesting to others
as well even though we may moved from the original question - Adopt or not
to adopt?
Please find my notes in-lined and tagged GIM2>>.

Regards,
Greg

On Sun, Aug 13, 2017 at 9:14 PM, Toerless Eckert <[e-mail]> wrote:

> 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.
>
GIM2>> I haven't stated that IGP would not play role. And if by "static"
you mean "instantiated by an SDN controller", then yes, that is plausible.
But we know how to build VPNs, L3VPN in particular. Why the same approach,
BGP or EVPN, not to use for BIER sub-domains? And support of N VPNs doesn't
seem as major problem these days either. As for updating the state when
underlay network changes, then we should consider this as multi-layer
network. Firstly, the underlay may be protected thus minimizing packet loss
in the overlay. And since the underlay is TE, we should use restoration in
the underlay as well which will preserve required characteristics for the
overlay network.

>
> > > 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.
>
GIM2>> I think I understand BIER-TE model and I believe that BIER+SR can
achieve the same results though by building underlay with more constrains.
Thus I don't see the value in BIER-TE work.

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