[Bier] Comments on draft-hfa-bier-pim-tunneling

[Antoni Przygienda <[e-mail]>]

Read the draft on the plane trying to figure out what’s that about. Observations


a)       First, the draft seems to indicate that it’s draft-rosen (6037) and I assume it’s talking about the P-G PIM which is generated by the PE and then first P is acting as BER. And it seems to concern mostly SSM. Just verifying …

b)       I’m suspicious of the 256bits argument somehow. Is the idea that running a single-SI BIER is somehow massively simpler than multiple-SI-s? The packet WILL split @ replication points & replication is necessary in any case (unless we have ingress rep for which BIER is not needed) so I don’t see how single-SI makes much of a difference.

c)       We do not need to burn a protocol bit for PIM albeit yes, it would be tad more efficient. PIM must be carried in either v4 or v6 frame which is its normal encoding and already fully supported by BIER encaps. Additionally, if PIM is stripped of v4/v6 encaps considerations would have to be made to all the PIM RPF & correct source/destination addresses checks in the spec AFAIR. Yes, the BER needs to look into v4/v6 packets to  see PIM being tunneled but if we try to accommodate every IP protocol with a bit, we’ll run out fast. Accomodating a protocol makes most sense when we talk heavy-volume dataplane such as maybe VxLAN if we can save headers for processing speed but PIM is a low volume control protocol and the check is trivial since it’s a well known next-protocol offset position.

d)       I think the moniker BRT is ill chosen. BIER does not do RPF and using “RPF” here to describe tracking of G-membership of P-BFRs is overloading the term in a confusing way IMO. Basically in overlay we should have a G to BFM mapping (and if necessary S to BFR-id derived from BIER packets) and nothing else. There is no “RPF” lookup per packet or anything like this which the moniker suggests (yes, one would say we do a “RPF” per “PIM join” but that somehow implies that such “RPF” can “fail and drop” which it cannot).

e)       The whole “RPF SPF lookup” in 3.1 for (S,G) joins will not work in general case AFAIS. Observe that BIER may NOT be IGP signaled (but e.g. controller based) or run subdomain over a MT sub-setting links or construct a different tree than SPF so this “PIM tunneled (S,G) overlay” seems to violate the separation of layers completely as proposed assuming that it can draw conclusions from IGP state (i.e. it considers the tunnel path somehow “backwards-computable” by the overlay making it not a tunnel but an encapsulation only).

If the whole (S,G) join architecture hinges on assumption that a “future” BIER packet’s source can be “figured out by computing SPF” then it is very restricted and those assumptions have to be spelled out very clearly. In general case an (S,G) join would have to be sent to all BERs that participate in the P-G IMO make is de-facto ASM is my impression.


Maybe I somehow miss the whole point completely given that the text is jumping between tons of technologies and seems to not state assumptions taken every time clearly …

--- tony