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

[Caitlin Bestler <[e-mail]>]

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?

    Presumably the application, or a utility library, translates each
    destination IP address into a
    bit position. This is safe because the mapping of IP address to bit
    position is stable.

    The host or the BFIR *extends* that bitmap to provide additional
    bits which are there for the
    benefit of intermediate forwarders which would not have build a map
    of all destinations for
    their own purposes. Edge BFRs would need to build such a map, but
    core BFRs with no clients
    directly attached would not have to. More importantly than not
    having to build it, they would
    not have to store it.

    What is the stability of these derived bits? Are we preventing
    transitory renumbering of internal
    links somehow? How often does the mapping of a destination IP
    address to intermediate paths
    to be followed hold? Is this something a user-mode BIER utility
    library, or a host stack, would
    have to be involved with?

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?

    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?