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:20 PM, Eric C Rosen <[e-mail]<mailto:[e-mail]>> wrote:


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

As I said in my message of July 3, it seems to me that what you are trying to do is to use BIER to create an NBMA network attaching a set of PIM routers.  Unless i'm missing the point, the makes your proposal independent of the application.  What you need to do is make sure all the PIM link procedures will run correctly on the NBMA network.  I don't see why ASM is a particular problem.

Correct. We will look at ASM as well for completeness.

Andrew> There are two goals:
Andrew> - Stay with a single SI to avoid packet duplication in a core due to a scale.

The BIER domain would certainly be easier to bound in size if it only includes the set of PIM neighbors on the NBMA "link".  But I don't think anything in your proposal is incompatible with the use of multiple Sets.

Correct.

Andrew> - Intro BIER in the core without a need to touch access domains - evolutionary intro of BIER.

There are other possible approaches as well.

If an application supports "segmented tunnels" (such as NG-MVPN does), it's not too hard to have a "BIER segment" across the core while using other multicast protocols (or ingress replication) in the access areas.

Another approach is to use NG-MVPN Global Table Multicast (RFC 7716) across the core (instead of PIM), in which case you can use BIER as the "tunnel type' across the core, without requiring core nodes to send PIM messages to each other.  Note that the default MDTs and data MDTs of "rosen mvpn" are global table multicasts, and GTM is easily used to connect multiple PIM areas together.  So this would be a feasible technique for doing "rosen mvpn" at the edges with BIER in the core.  Which technique is better under which circumstances could be explored.


The slides Hooman will present will explain how and why we gravitate towards this solution.


Tony> We do not need to burn a protocol bit for PIM

I agree with Tony that there doesn't seem to be any need for the Proto field to be "PIM" rather than "IPv4" or "IPv6".   (At least, no architectural reason.  In the implementation, perhaps this would be the trigger that caused the hardware to associate the packet with an "incoming interface" of "BIER" ;-)  If so, we'd have to explore that a bit deeper.)

Tony> The whole “RPF SPF lookup” in 3.1 for (S,G) joins will not work in general

Well, this is the usual problem of how do you find the "upstream multicast hop" when the multicast routing neighbors are not also unicast routing neighbors.  Generally the solution to this problem will depend upon the unicast routing environment.