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

From: Eric C Rosen <[email-masked]>
Date: Mon, 3 Jul 2017 17:22:18 -0400

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.

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

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

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

- Will this work with BIDIR-PIM, or is that out of scope?

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 20 Jul 2017 10:41:42 +0000

Some follow up comments below.

> -----Original Message-----
> From: BIER [mailto:[email-masked]] On Behalf Of Eric C Rosen
> Sent: Monday, July 3, 2017 11:22 PM
> To: BIER WG <[email-masked]>
> Subject: [Bier] Comments on draft-hfa-bier-pim-tunneling
> 

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.

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

> 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

> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 20 Jul 2017 14:04:21 +0000

Inline (HB>)

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Thursday, July 20, 2017 6:42 AM
To: Eric Rosen <[email-masked]>; BIER WG <[email-masked]>
Subject: Re: [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.

HB> Yes

HB> Yes

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

HB> The ideal here a simple mech to signal S,G through a BIER core, as mentioned before . We could of introduce a TLV in BIER header but we did not want to muck around with BIER header. So we decided to go with tunneling PIM joins/prunes through BIER. I will talk more about this face to face.

HB> Yes

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

Jeffrey