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

[Eric C Rosen <[e-mail]>]

According to the draft:

    Currently, BIER-TE does not support BIER-sub-domains and it does not
    not use BFR-id.  BIER-TE headers use the same format as BIER headers
    (BFR-id is set to 0)

If the BFIR-id field in the BIER header is set to 0, it is impossible 
for the BIER payload to be an MPLS packet whose label stack begins with 
an upstream-assigned label.  That's because the BFIR-id provides the 
context in which the upstream-assigned label is interpreted.

Is that the intention?  That would seem to mean that BIER-TE cannot be 
used to support MVPN.

 From section 3.2.4:

A "local_decap" adjacency passes a copy of the payload of the BIER-TE
packet to the packets NextProto within the BFR (IPv4/IPv6,
Ethernet,...).

These local_decap adjacencies sound an awful lot like BFER-ids. Don't 
you need one for each BFER?  So the BitString has to have a bit for each 
BFER and a bit for each link that is along the path to any of the BFERs? 
  Wouldn't this require that the number of BFERs be much less than the 
number of bits in the BitString?

 From section 4.9 of the draft:

    In a large network, multiple BIFT may be necessary, each one
    identified by a different SI value in the BIER header.

Well, the only BIER encapsulation referenced by the draft is the MPLS 
encapsulation, which does not have an SI value in the BIER header. 
Probably you need to point out in section 3.3 that the MPLS label needs 
to be associated with an SI, and modify section 4.9 to say that the SI 
is inferred from the label.

Even so, I don't really understand how this would work.  In ordinary 
BIER, the bits identify the BFERs.  If for a particular packet you have 
more BFERs than bits, you can always make two packets, and send each one 
to (say) half of the BFERs.  In BFR-TE, the bits identify the links over 
which the packet must flow.  If a particular packet has to flow over 
more links than can fit into the BitString, you can't just make two 
packets, and have each one traverse half the links.   I think this needs 
a bit more explanation.

Perhaps it is sub-domains rather than SIs that are needed here.  One 
could in theory have a sub-domain for each flow, and in that sub-domain 
you'd only have to assign bit positions needed for that flow.  It seems 
like it might be challenging though to figure out the least number of 
sub-domains you actually need for a given set of flows.

BTW, the references need updating.