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

[Eric C Rosen <[e-mail]>]

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.

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.

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.

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.