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

[Toerless Eckert <[e-mail]>]

On Mon, Oct 12, 2015 at 02:34:20PM -0400, Eric C Rosen wrote:
> I don't think the BFIR-id is needed for BIER forwarding, it's only
> needed if the multicast flow layer at the BFERs needs to do some sort of
> RPF check. I don't think BIER and BIER-TE are different in this respect.

Indeed.

> Right, in BIER-TE forwarding the BFIR-id doesn't require a bit in the
> BitString, so eliminating the BFIR-id doesn't really seem to provide
> much value.

16 bit header saved. 

> With regard to the issue of not having enough bits to represent the
> entire multicast distribution tree ...

Right...

> >[Toerless] Section 4.3 explain how Leaf BFER effectively require no
> >bit (sorry typo: 4.3:s/BFIR/BFER/, done for -02). Eg: just one bit
> >per link to leafs, and one shared (local decap) bit for all leafs in
> >the network.
> 
> I didn't really understand this.  How does a node know whether it is a 
> leaf (a BFER) for a particular packet?  Doesn't this mean that every BFR 
> through which a packet passes is going to have to figure out whether it 
> is supposed to be a BFER for that packet?  I'd like to see the details 
> of how that would work.

Conroller determine if BFR is BFER:
  Is there a service edge using BIER-TE and BFR could be receiver
  on some of these services ?  Ok, you're a BFER.

Controller determines what bits are needed to support BFER:
  Is it even feasible and if so, desirable to send packets
  into this BFR and have them transit towards another BFR ?
  No ? Ok, you're a leaf BFER. 

If BFR is leaf BFER, then controller only assigns bit to the
links leading up to the leaf BFER, not the BFER itself.

For all non-leaf BFER, controller assigns an individual bit.

If there are one or more leaf BFER in network, controller assigns
one "shared leaf BFER" bit. Thats set to have local decap entry
in all the leaf BFER. It can be shared, because it would only be
reset when it passes through some BFR that has it set, and given
how all BFR that have it set are leaf BFR, this will not happen. QED.

> BTW, however it works, it will probably require 
> knowing the BFIR-id, unless that can be inferred from the sub-domain 
> that is implicitly identified by the BIER-MPLS label.  (Consider, e.g., 
> a case where a given flow is traveling on two different TE trees, 
> perhaps from different BFIRs, but a given transit node is on both trees.)

I don't think BFIR-ID plays a role here. 

[...]
> Assuming we replace "SI" with "sub-domain", is this the same as Neale's
> suggestion:
> 
> >[Neale] perhaps one could consider one or more uni-directional
> >BIER-TE sub-domains rooted at each BFIR. Each individually signalled
> >sub-domain comprises a sub-set of the BFERs (and the links to
> >traverse to them) that the BFIR needs to address. Flows can then map
> >onto one or more of these sub-domains. This scheme keeps the number
> >of sub-domains scaling with network size (as with SPF-BIER sets),
> >rather than number of flows.

Possibly the same, yes. Neal doesn't belabor the unicast/MPLS part
"how to get a BIER packet from any BFIR to some remote subdomain" as i do.
Not sure if he envisions something different than i or just thinks
that piece is obvious.

> So each sub-domain would be a sub-tree of the tree from a given BFIR.
> You unicast-tunnel a packet to the root of a sub-domain, and then let 
> BIER distribute the packet down the sub-tree.
^^^^^^ BIER-TE

> The number of sub-domains 
> is then proportional to the number of BFIRs (which is still a lot of
> sub-domains), and each transit node would have to determine for each
> packet whether it needs to consume that packet or just pass it along.

No, not really.

Lets run a simple example: 5 country network. 1000 BFER, each country
200 BFER, 3 routers in each country connecting to core. Call them 
them sub-domain BFIR if you want. Controller allocates
one sub-domain per country. Fills up 256 bitstring with in-country
BFER and in-country links Aka: lets say all relevant links between
sub-domain BFIR and BFER are < 56.

Lets look at BFIR service lookup for some IPTV (S,G) on ANY BFIR
across the whole network: OIF list of 5 replications, each replication
has unicast/MPLS label of one sub-domain BFIR follows by that BFIRs
label for the subdomain of interest, followed by the BIER bitstring for
the "in-country bits".

Scales with number of BFER + number of relevant replication
transit hops.  In above example, maybe 20% of BFER ???

If you'd try to run this example with BIER instead of BIER-TE and
did randomn BFR-ID == SI allocation, you may end up sending more copies
across a lot of links. Eg: when you end up with BFR-ID with 2 different
SI in a country. So the logic of allocating BFR-ID or sub-domains
is really necessary/beneficial almost as much in BIER as in BIER-TE
in these type of examples.

> Part of the BFER processing would be to figure out for each packet (a)
> am I supposed to receive this packet and (b) did I receive it from the
> sub-domain over which I'm expecting it?

Hmmm... no, can't parse that. knowing which sub-domain a packet is
for is like BIER via the label when MPLS encap is done (otherwise it
wouldhave to be in the BIER header). Punting to higher layer is
just based on having a bit with local decap and as explained above,
the controller can intelligently assign this shared for leaf BFERs.

> It seems like there are a lot of details to be added, and some of them
> might be dependent upon the multicast flow layer.

Let me know specifically what piece of explanation you'd like to see.
If the above example, maybe with a picture would help, thats easy.

> >[Toerless] Am i missing references, or where the numbers of the
> >drafts references too old, even for the time when i ran the xml2rfc?
> 
> The references are to the old individual documents rather than to the WG
> documents.

Arghh... ok. stupid me. I was wondering what xml2rfc wouldn't
update automatically.

> >[Toerless] rings require also only one bit per node (local decap),
> >and a single shared bit for the ring (Section 4.6) (or even for
> >multiple rings).
> 
> I don't quite understand from section 4.6 why a given packet will not
> revolve around the ring forever, as the "ring bit" only seems to get
> reset when the packet leaves the ring.  Also, if the "ring bit" gets 
> reset when a packet leaves the ring, how do you use one bit for multiple 
> rings?  Perhaps I've misunderstood something.

 "On BFR2, the adjacency also points to the
   clockwise neighbor BFR1, but without DNR set.  "

DNR bit is part of the adjacency in the BIFT, so only
the copies sent across the ring adjacencies will have it set, and then
we do not set DNR towards the end of the ring before it would loop. 

Multiple rings is just an example. DNR allows you to save bits
in bitstring whenever you are fine all BIER-TE traffic is flooded
across that sub-topology. Just set up in the BIFTs appropriate
adjacencies to flood (loop free) across the topology.

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