Re: [Bier] New Version Notification for draft-pfister-bier-over-ipv6-00.txt

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

Toerless, nice example.  But let's look at it more closely.

>                                          |-- Rcv1
>                              --- BFER1 --|
>                             /            |-- Rcv2
>        Src ---- Rtr --- BFIR
>                             \            |-- Rcv3
>                              --- BFER2 --|
>                                          |-- Rcv4
> 					|
> 					|-- Rtr2  ---- Rcv5
>
> Src sends one IPv6 unicast packet indicating (Rcv1,Rcv3,Rcv4). It will have a prefix
> owned by BFIR.
Actually, in this example, I think Src is the BFIR, what you call BFIR 
is actually just a BFR at the border of a BIER domain.

What does "owned by BFIR" mean?  Is the prefix jointly "owned" by all 
the BFRs bordering the BIER domain?  What about non-BFRs bordering the 
BIER domain?  What keeps the packet from going to them instead?

If Src thinks that the prefix is on the local network, it won't send the 
packet to Rtr, it will instead try to figure out the unicast MAC DA 
corresponding to the IP destination address.  This DA doesn't exist, so 
the packet will get dropped.  But if Src doesn't think that the prefix 
is on the local network connecting it to Rtr, it may send the BIER 
packet out a different interface.  Where will the packet end up then?

What if Src is doing load balancing among the default routers on the 
LAN, or among its interfaces?  For a given flow, the "IPv6 destination 
address" will change from time to time, which means the load balancing 
hash for that flow will change from time to time. This is the 
"non-deterministic ECMP" problem discussed in the architecture.  But 
since Src doesn't actually support BIER, it cannot use the solution 
described in the architecture draft.

What if there are receivers on the same LAN as the Src?  How will those 
receivers get the BIER packets sent by the Src?  Since Src thinks the 
BIER packet is a unicast packet, it will encapsulate it in a unicast 
ethernet frame whose MAC DA is a MAC address of Rtr. Since Rtr is not a 
BFR, Rtr will remove the ethernet header and forward the IPv6-BIER 
packet towards (let's say, for the sake of argument) the node you call 
BFIR.  How will BFIR get any copies of that packet back to the receivers 
that are on Src's subnet?  Sending the BIER packet (with modified 
BitString) back to Rtr will cause a loop.

> There it will be replicated by BIER. Copies arriving
> at BFER1,BFER2 will be converted back to IP unicast packets, one copy to Rcv2 from
> BFER1, one from BFER2 to Rcv3, one from BFER2 to Rcv4.

Suppose Src had an IP multicast packet to send, and encapsulated it in 
an IPv6-BIER header.  In that case, a BFER needs to decapsulate the 
packet and multicast the payload to the LAN on which the receivers 
reside.  How does a BFER know whether to (a) decapsulate and multicast 
or (b) whether to replicate, overwrite the destination address, and 
unicast?   I hope the answer isn't that the BFER needs to inspect the 
payload and guess what the hosts are expecting.

BFER2 needs to know which BFR-ids represent hosts on any particular LAN 
to which it is attached.  A BFR-id is just a shorthand for a BFR-prefix, 
i.e., for an IP address.   If BFER2 wants to use unicast replication to 
transmit on the last hop, why not just use the actual IP addresses of 
the receivers?

I don't see how BFER2 can get a BIER packet to Rcv5.  Rtr2 will at best 
loop the packet back to BFER2, and at worst the packet will get 
forwarded (through a route not necessarily shown in the above picture) 
all the way back to "BFIR", which "owns the prefix".

> How about supporting remote receivers like Rcv5 ? Sources can be remote so
> it would make sense to allow bidirectional support. Might need some signaling
> to BFER2 to map a remote IP address to a bit.
>
Each BFR and non-BFR can have a host route for every possible receiver, 
and some magic can be used to associate a BFR-id with each host route.  
That would eliminate some of the routing and looping issues.    There 
might be a few scaling issues though.

BTW, if one wants the BFR-ids to represent receiver hosts, one is going 
to need a lot more BFR-ids than if the BFR-ids represent BFERs.  So one 
would certainly  want to use an encapsulation that allows more than a 
64-bit BitString.  One could try to compensate for the very short 
BitString by having lots of sub-domains.  Then for each application (or 
perhaps each flow) one could try to assign the BFR-ids densely.   But 
we've heard that sub-domains aren't necessary for this encapsulation.  
More importantly, if a short BitString leads to more sub-domains, we 
will see an increase in the operational complexity and signaling load of 
the scheme.