Re: [Bier] AD Review of draft-ietf-bier-te-arch-09

[Tony Przygienda <[e-mail]>]

given it's IETF weeks and I'm staying up to 3am every day it's a good
possibility to catch up on lots ietf threads/drafts ;-)

inline

On Tue, May 18, 2021 at 11:41 PM Toerless Eckert <[e-mail]> wrote:

> On Fri, May 14, 2021 at 01:14:43PM -0700, Alvaro Retana wrote:
> ...
> >
> >      BIER-TE can co-exist with BIER forwarding in the same domain, for
> >      example by using separate BIER sub-domains.
> >
> >   The result of separate sub-domains is more akin to ships-in-the-night
> than
> >   having them be "mixed": in the same sub-domain using a single BIFT
> >   (populated by different sources).   Is this correct?
>
> The way in which the BIER-TE draft defines BIER-TE forwarding, it is
> exclusively
> "owning" a BIFT. This is because the code, e.g.: Figure 15 shows the
> bit-reset
> semantic for all bits to use BIER-TE ([1] vs. [2]). So, what you call
> "mixed"
> is not part of the draft.
>
> Of course, implementations can easily build a single implementation of
> forwarding
> across BIER/BIER-TE, even with semantic, BIER vs. BIER-TE different for
> every bit,
> but to me this is just implementation optimization. Reason is that i have
> not
> identified good operational benefits to make this part of the BIER-TE
> architecture.
> (aka: use case with some bits using bier othre bits in same bitstring
> using bier-te
>  bit-reset logic).
>
> However, your ships-in-the night semantic is probably incorrect.
> Even BIER alone can already have multiple BIFT per sub-domain,
> because according to rfc8279, you need a combination of (sub-domain, bsl)
> to map to a BIFT, not just a sub-domain.
>
> Here is suggested text to help clarify:
>
> | When BIER-TE is used with rfc8296 encapsulation, the bift-id identifies
> an SI,
> | a sub-domain, and a BitStringLength (as specified in rfc8279) AND
> whether to
> | use BIER or BIER-TE forwarding for this bift-id.
>

yes, it's crucial to define the "separation" boundary in the architecture
document here.
"ships in the night" is too loose a term IMO, we need clear delineation, I
think
subdomain is a natural one (which Alvaro seems to have divined from the
document ;-).
So a BIER domain can mix TE and vanilla and
I don't see anything wrong with that, such things were one of the reasons
to do sub-domain, so we can do MT or flex-algo per sub-domain or completely
change the
semantics of the bitmask (well, as long it does packet replication in some
form ;-). I think we're in sync here.


>
> >   §3.3 speculates about potential "definitions in BIER encapsulation
> >   specifications" to "distinguish BIER from BIER-TE packets"
>
> Yes. we had a draft to that end (one more bit in BIER header used to
> indicate
> BIER/BIER-TE mode), but that was not met with much love by the WG back
> then,
> but i see no good reason to now mention this as a still open option given
> how
> rfc8279 also did not constrain itself to only rfc8296 encap.
>

and as you know the wall you have to climb to justify a new encapsulation
in BIER or even bend bits
is famously high ;-)
So unless a use case is presented that cannot be met by the MPLS or
non-MPLS encaps the WG
has proven considerably prudent so far in this respect ;-)


>
> >    -- and offers a
> >   workaround if the MPLS encapsulation is used.
>
> Not a workaround, See above proposed text "|".
>
> In the rfc8296 forwarding plane we can easily have the same
> (sub-domain, bsl) with BIER as well as BIER-TE by just giving them
> different bift-ids. And that works for both mpls and non-mpls.
>
> The routing protocol signaling right now would only work for BIER semantic
> bift,
> but that is fine as we do not use/need the IGP BIER extensions for BIER-TE.
>

nothing precludes BIER-TE from inventing a distributed protocol for TE IMO
or
do things like multicast RSVP-TE for BIER-TE AFAIS. At least
architecturally it's all fair game.

Given we're starting on adjournment to  8279 I think it would be a nice
example to
show how BIER-TE fits nicely into BIER architecture that properly decouples
L2 & L3 abstractions it relies on from the semantics of BIER (*sub)-domain
and its behavior
as abstract replication capable  L2.5 substrate.

-- tony