Subject: [Bier] Observations on https://tools.ietf.org/html/draft-ietf-bier-architecture-01 and resulting change request

From: Tony Przygienda <[email-masked]>
Date: Sun, 19 Jul 2015 18:19:18 -0700

As individual contributor & co-author: There was a longish discussion after
the newest extensions of bier architecture for nodes supporting multiple
BitStringLengths has been published and I had it on my list to summarize
here the unwritten assumptions that emerged so it's a clearer read and then
add a comment from my side for further discussion. This all pertains pretty
much to extensions of section 6.10

Let's start with an example and then see the problems in what today's
architecture document draft mandates (i.e. no signalling of conversion
capability between multiple BMLs in a node, each node independently making
decisions during compatibility check).  Parallel links are the same link
simply to allow different color coding of paths.

​

​

alpha is trying to fwd BIER packets to delta and following the shortest
path (i.e. beta1,beta2,gamma in red) will NOT succeed to deliver the
packets since beta1 will convert from A to B for beta2 and gamma cannot
convert it into A again.

Observation a: if the bitstring compatibiilty check is disabled and normal
SPF is used, this will blackhole. Even with compatibility check, Point
6.10.1 choice 1 is incorrect in the assertion that choice 2 of 6.10.2 will
not blackhole (choice 3 won't but whether use choice 2 or 3 is impossible
to determine in current architecture and choice 3 is basically unicast).
Compatiblity check, even if using option 1. without signalling of which
path computation is used may blackhole here when shortest-path is used.
Observation b: using a different path computation could yield
 alpha,gamma,delta (blue) which does not need conversion and does not
blackhole. However, the nodes have all to agree on the computation,
otherwise blackholes may occur (a node fwd' towards another node may choose
a path which takes the packet away from what the originating node consider
shortest, observe however that BIER loop protection will cause @ most a
micro-loop. In this example if gamma runs SPF it will drop packet since it
wants to fwd it towards beta2 [black link] even if alpha assumes it follows
the blue path based on the computation it's running).
Observation c: Nodes also need to agree whether conversion is supported
even if they agree on the path computation. Shortest path that does not
blackhole here is beta1,beta2,beta3 (green) but if beta2 would assume doing
a computation that all nodes convert, it would fwd' to gamma while gamma,
since it cannot convert, would loop back @ beta2, i.e. red is the shortest
path assuming e'one can convert but it's a blackhole.

There are more observations but that's just a starting point to following
conclusions and my comments/request on the architecture:

What's my take:
a) it has to be understood that the architecture with multiple BMLs may
blackhole if simply SPF is used no matter what. With compatibility check
the blackholing can be only avoided only if e.g. a 'BML restricted SPF' is
run that includes nodes only with the packet's BML (i.e. all nodes not
supporting the BML are excluded). Such a computation may blackhole even if
a 'conversion path' is avaialble.
b) if conversion is supported, the nodes have to signal conversion to allow
for a 'smarter' path computation that can take into account this property
when computing paths. In this example the shortest, converging path is
alpha (A),beta1 (A),beta2 (B),beta3 (B),delta (A) (green) which is shorter
than the 'BML restricted SPF' alpha(A),gamma(A),delta(A) (blue) while the
simple SPF will blackhole no matter what  alpha (A),beta1 (A),beta2
(B),gamma (B) (red)

*So, to keep the architecture pliable to solve all those problems in the
signalling/IGPs in the future (if indicated) I strongly suggest:*

*A. to remove the unnecessary restriction in all places "It should be
understood though that the BFIR cannot determine by signaling whether
those procedures have been deployed.". **The architecture must not mandate
whether such a signalling is deployed. *
*B. Add to IGPs today an optional TLV signalling BML conversion capability
to allow in the future for 'smart path computations' that can take those
things into effect if necessary. Today those TLV should be absent and
indicate 'no BML conversion capability'.  Already this can serve to warn
the user about blackholes or locally decide between option 2 and 3 to
prevent blackholing. *

I write this email to kick off a discussion in wider forum on this topic. I
am concerned that we're twisting here the 'architecture' into 'simplest
possible implementation document even if it has stable blackholes'.  The
role of an architecture is NOT to restrict the solution space to simplest
implementation, it is to allow for the technology to evolve in
interoperable way for a long time to come. Yes, today's implementation
mechanisms (IGP documents) should be kept as simple as possible (omitting
optional path computation type TLV, optional BML conversion TLV assuming
lack of those signals simplest defaults but with wide deployment we will
likely start to see the solutions stretching to 'fill in' the architecture
which must be pliable enough to hold up lest we end up with an awful
'bag-of-bandaids' because architecture tried to 'keep things simple').

--- tony