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

Some follow up comments below.

> -----Original Message-----
> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Eric C Rosen
> Sent: Monday, July 3, 2017 11:22 PM
> To: BIER WG <bier@ietf.org>
> Subject: [Bier] Comments on draft-hfa-bier-pim-tunneling
> 
> It seems to me that what this draft really proposes is a way to use BIER
> to create an NBMA (Non-Broadcast Multiple Access) data link on which PIM
> can be run.
> 
> If one looks at it that way, there is no interaction with the MVPN layer
> at all.  To MVPN, it looks like the P-tunnels or default-MDTs/data-MDTs
> are created by PIM.  The fact that the network core is acting like an
> NBMA data link is invisible to the application layer.  Thus I don't
> really understand why sections 5 ("ASM") and 6 ("MVPN") are needed.

Completely agree. It should be completely orthogonal to MVPN.

MVPN was initially mentioned with the context that a Rosen MVPN network could have many PEs (more than the BitStringLength). To avoid sending multiple copies via BIER, the MVPN PEs would not BFIR/BFERs; rather, only a smaller core would be running BIER, and when the PIM signaling for the provider tunnel reaches that core, the procedures in this draft kicks in. As far as BIER is concerned, this is for pure PIM. No MVPN involvement.

Of course similar procedures could be used for Rosem-MVPN where the MVPN provider network and BIER domain are the same. I think that's what section 6 is trying to say, but in that case, there is no PIM provider tunnel at all. The signaling is for C-multicast (so there is a need for something similar to Route Distinguisher), not for provider tunnel.

> 
> There are a few questions that might deserve some more attention:
> 
> - Part of the proposal is that the Join/Prune messages are unicast,
> using a BIER  header with a single bit set in the BitString.  That will
> certainly work, but it's an unusual way to create a unicast tunnel.  I
> realize it does have the advantage of already including the BFIR-id in
> the encapsulation header.
> 
> - Since the BIER edge routers are PIM neighbors of each other, it seems
> like they should be multicasting PIM Hellos to each other. (The draft
> doesn't really say how the BIER edge routers running PIM are expected to
> identify each other; once they do identify each other, multicasting
> Hellos using BIER should be simple.)

I wonder if PIM hellos are needed among BFIRs/BFERs. I remember one flavor of Rosem-MVPN (in the MS-PMSI version?) proposed to remove the need for Hello.

> 
> - The lack of Join Suppression is worth at least mentioning.

Right, it should mention that Join Suppression is naturally turned off because of the unicast, and it's necessary for leaf tracking.

> 
> - There are various PIM procedures that may or may not need to be
> modified to deal with an NBMA data link: DR election, Assert, etc.  If
> the usual PIM procedures need to be modified, that has to be discussed.
> (Even if they don't need to be modified, this should be discussed.)
> 
> - When a data packet is received, is it necessary to do an RPF check
> against the BFIR-id?  If so, then there is an issue of just what happens
> when a BFER (for a given data flow) changes from one tree to another
> (e.g., changes from the shared tree to the source tree); is the RPF
> check altered when a new Join is sent, or when the first data packet of
> the flow is received from the newly chosen tree, or somewhere in between?

For SSM it may be needed to prevent transient loss/duplicate when topology changes (e.g. switching from one BFIR to another).

For ASM the draft says it also works but that may need further discussion (besides RPF check).

Jeffrey

> 
> - Will this work with BIDIR-PIM, or is that out of scope?
> 
> 
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier