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

["Dolganow, Andrew (Nokia - SG/Singapore)" <[e-mail]>]

Inline

Andrew

Sent from my iPhone

On Jul 18, 2017, at 10:56 AM, Antoni Przygienda <[e-mail]<mailto:[e-mail]>> wrote:

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 …

The solution we are targeting runs Rosen MVPN in the core. And yes SSM is our main target.

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.

There are two goals:
- Stay with a single SI to avoid packet duplication in a core due to a scale.
- Intro BIER in the core without a need to touch access domains - evolutionary intro of BIER.


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.

Let's discuss in Prague.

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).

This is bot trying to be a general solution that will work with every BIER deployment. It intends to solve brown-deployment use caee in some pretty typical architecture deployed today.

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 …


Let's go over confusing parts tony so we can clarify and avoid those in the text.

Andrew
--- tony

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