Re: [Bier] Questions on draft-eckert-bier-te-arch-01

[Toerless Eckert <[e-mail]>]

Inline.

On Fri, Oct 16, 2015 at 02:47:33PM -0700, Caitlin Bestler wrote:
> I think I'm understanding BIER-TE finally, but I have a few questions to 
> confirm my understanding.
> 
> How does an application use this?
> 
>    In particular, how is this done so the overhead of determining the
>    end-to-end path is not
>    imposed on the host or BFIR on a per packet basis?

I don't think we've done a lot of brainstorming how to do end-2-end BIER
where the two ends are actual applications instead of transport services
gateways, eg: BIER-PE or the like (encap/decap native IP multicast or
MPLS multicast).

Assuming we had end-to-end bier, for BIER proper you'd have a 1:1 mapping
between receiver and a bit in the bitstring, and its a matter of the
API we build whether or not we hide these bitstrings. In BIER-TE you'd have
to have like in other TE solutions some upfront magic that determines the
shape of the overall tree. Eg: PCE controller or so. This is not a BIER-TE
problem, this is a TE problem.

If you want to build something like Steiner trees than the overall tree
would want to change when you add/delete a receiver. If thats the
traffic optimization needed, then worst case the PCE controller would
need to give you for each possible combination of receivers a different
bitstring. Not really difficult, but potentially a bit of upfront
calculation depending on how many receivers you have and how
many subsets are of interest. Again, this alculation would need to be
done however you'd want to do TE, BIER or whatever else. Just the output
being a bitstring is BIER-TE specific.

If the path towards each receiver should not change whether or not
other receivers are included into the tree or not, then it gets
easier: The PCE controller would give you for each candidate reciver a
bitstring, and the actual bitstring you want to use in your BIER
packet is just the OR of the bitstrings for each receiver.

>    What is the stability of these derived bits? Are we preventing
>    transitory renumbering of internal links somehow?

Assignment of bit-indices to links or BFRs or the like is all just
software in the BIER-TE controller software, For path selection it
may consult some external generic PCE controller or perform those
functions itself.

You can reuse a particular bit-index as soon as that bit-index is
not used for anything else in any running BIFT or BFIR adjacency.
This is really only a problem when the network growths. When you
have link-failure, you do not reassign bits, you just need to update
the bitstrings on the BFIR for packets to take alternative paths.

>    How often does the mapping of a destination IP
>    address to intermediate paths  to be followed hold?

IN BIER-TE you don't see the path in the bitstring, and it changes
automatically because of routing. In BIER-TE its fully or partially
visible. Its really just a matter of your policy when/how you want to
change it. Because of varying load ? Link/node failures, network
expansion... 

> Is this something a user-mode BIER utility
>    library, or a host stack, would
>    have to be involved with?

If a BIER packet is created by an application level entity then it
needs to insert the right bitstring, but as suggested above it might
consult an external entity like a PCE controller or BIER-TE controller
to get this information. Such interactions have not been defined yet.
But likewise in normal BIER, you'd today need manual config or be
able to retrieve IGP information to map from IP-address to BFR-id.

> What portion of the bitmap would be needed for the "derived" bits?
>
>    What is a reasonable ratio between true destination bits and
>    intermediate forwarding bits?

See one of my last emails. Depends on how much traffic engineering you
want/need. I think most deployment should be able to use less than 50%
of bits.

>    How does this compare to using a TRILL-style encapsulation with the
>    outer-BIER header containing
>    *only* the forwarding bits and an inner BIER header containing only
>    the ultimate destination bits?

Depends really on what you want to achieve. Easier to answer based
on an explicit example if you have one...

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