Re: [Bier] End-to-end BIER

[Caitlin Bestler <[e-mail]>]

On 10/29/15 10:15 AM, Eric C Rosen wrote:
> [Caitlin] Each bit position would represent and end-station rather than
> a BFER. The application would map a destination IP address to a bit
> position (or bit-positions for BIER-TE).
>
> This is really just a control plane issue.
>
> [Caitlin] allowing the actual BFER to use multicast Layer 2 delivery 
> is more direct. There is no need for BFERs to inform BFIRs that 
> multicast delivery will be used. It makes no difference to the other 
> BFRs. You can even make a case that this is already allowed under the 
> "no harm no foul" rule.
>
> This seems a bit more problematic to me, as the LAN might attach to 
> multiple transit BFRs.  Consider a topology like:
>
>         |----BFR-B---Endpoint-1
> BFR-A---|      |
>         |----Endpoint-2
>
> That is, BFR-A, BFR-B, and Endpoint-2 are on the LAN, while Endpoint-1 
> is downstream of BFR-B.  BFR-B also has another interface that 
> attaches to Endpoint-2.  All links are equal cost to the IGP.
>
> Suppose BFR-A receives a packet whose BitString says that the BFERs 
> are Endpoint-1 and Endpoint-2.
>
> With existing procedures, BFR-A sends BFR-B the packet with only 
> Endpoint-1's bit set, and BFR-A sends Endpoint-2 the packet with only 
> Endpoint-2's bit set.
>
> If BFR-A uses layer 2 multicast to send a single packet to both BFR-B 
> and Endpoint-2, Endpoint-2's bit will still be set in the packet 
> received by BFR-B.  So BFR-B will forward the packet to Endpoint-2, 
> and Endpoint-2 will now receive two copies of the packet.
>
> Another problematic scenario:
>
>
>         |----BFR-B---Endpoint-1
> BFR-A---|      |
>         |----Endpoint-2
> BFR-C---|
>         |----Endpoint-3
>
> Here BFR-C and Endpoint-3 are also on the LAN.  Suppose BFR-A receives 
> a packet (from one of its other interfaces) whose BitString identifies 
> Endpoint-1 and Endpoint-2, while BFR-C receives the same packet (from 
> one of its other interfaces), but with a BitString identifying only 
> Endpoint-3.  When BFR-A and BFR-C multicast the packet to the LAN, we 
> need to make sure that BFR-A and BFR-C don't receive the packet from 
> each other, and that BFR-B doesn't receive the packet from BFR-C.  If, 
> for example, BFR-C gets the packet from BFR-A, it will conclude from 
> the BitString that the packet still needs to be sent to Endpoint-1 and 
> Endpoint-2.
>
> It would be an interesting exercise to see if one could state a set of 
> enforceable applicability restrictions that eliminate these problems.
>
> The various proposals for MLD/IGMP/PIM overlays address problems like 
> this, but the solutions are not at the BIER layer, so I don't think 
> they apply directly to the case of end-to-end BIER.
>
I'm not certain what the correct phrasing is in routing terminology, but 
going down one layer doing an L2 local-only delivery
is remarkably easy. Each L2 subnet knows its boundaries, and there is 
never an ambiguity about whether a given link is being
used to *forward* and Ethernet frame as opposed to *routing* an IP datagram.

If a BFER does not know how to do a local only L2 multicast then it 
should probably refrain from using that solution.

The fact that a spontaneously appearing MRouter appearing without notice 
would create problems in a WAN environment
is not a reason to avoid using this optimizaton in a datacenter where 
all forwarders and routers are known and the only
question to be determined dynamically is which of them are up.