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

[Tony Przygienda <[e-mail]>]

On Tue, Jul 18, 2017 at 10:20 PM, Eric C Rosen <[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.
>
yes, that's why the heavy focus on the SSM in the document threw me a bit
as well.


> 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.
>
neither do I and it still eludes me why just having 256 bits simplifies
things much or should be enshrined in this document. We may have a small
section saying "things are _even_ easier if you do 256 bits and don't have
to replicate" but now it sounds like the solution limits itself to 256
bits.


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

7716 is a very clean solution here to delineate the boundaries without
necessity of PIM signalling as first impression. Is the idea though to run
on PE both sides of BGP signalling or on the first P-router (which would
necessitate BGP on the P router if I'm not mistaken) ? I think it's P
routers since otherwise we need BFR-id per PE which defeats purpose of this
draft. Then how do we stitch the two BGP's together? core gets another AS
and we run EBGP PE-P and we stitch via inter-AS I-PMSI or something like
this?


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

I didn't think it through fully but there are so many PIM procedures that
having a JOIN without the IP encaps is likely to cause problems anyway (by
gut feeling).


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

yes, got it. Thinking through 7716 it looks tempting to me given it thought
through all the SFS/UMH scenarios.