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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

With the two stated goals:

- Stay with a single SI to avoid packet duplication in a core due to a scale.
- Intro BIER in the core without a need to touch access domains - evolutionary intro of BIER.

I think it is clear that MVPN is completely orthogonal. The BFIR/BFERs are not MVPN PEs, and section 6 about MVPN should be removed.

The P-BFIR and P-BFER terms are really confusing. They should simply be replaced with BFER and BFER, or Downstream PIM/Protocol Border Router (PBR as in the GTM RFC) and Upstream PBR respectively.



   In case of PIM ASM the procedure for LEAFs joining RP or the source

   is same as above. The unicast (source registration) traffic from

   source to RP will be flooded throughout the BIER domain as regular

   unicast traffic without BIER involvement.



A nit: a unicast packet is not “flooded throughout” J

Some more details about ASM will need to be examined and spelled out.

6<https://tools.ietf.org/html/draft-hfa-bier-pim-tunneling-00#section-6>. Draft Rosen multicast vpn behavior

   Over the years draft rosen mvpn has evolved with many different type

   of signaling.



   As an example, with AD and C-Multicast signaling of PIM or C-

   Multicast of PIM and AD of BGP.



   The above mechanism works with draft rosen mvpn as long the C-

   multicast signaling is done via PIM. The provider PIM for MVPN can be

   forwarded from Root and LEAF PE with above explained mechanism.



If we’re talking about provider PIM, then C-multicast signaling is irreverent.
If we want to use C-multicast signaling for leaf tracking for BIER (when the MVPN provider network and BIER domain are the same), then there is no need for PIM provider tunnels. Just BIER “tunnels”. The C-multicast signaling will need to tell for which VPN it is.



   The multicast traffic has to be forwarded via GRE tunnel. That said

   the AD signaling can be done via MP-BGP.



What is the “AD signaling” here? For C-multicast? The paragraph above says “as long .. is done via PIM” J



   Future drafts will address the NG-MVPN and MPLS tunneling.

For NG-MVPN, draft-ietf-bier-mvpn already covers it?

Jeffrey

From: BIER [mailto:[e-mail]] On Behalf Of Dolganow, Andrew (Nokia - SG/Singapore)
Sent: Tuesday, July 18, 2017 11:18 AM
To: Antoni Przygienda <[e-mail]>
Cc: [e-mail]
Subject: Re: [Bier] Comments on draft-hfa-bier-pim-tunneling

Inline

Andrew

Sent from my iPhone

On Jul 18, 2017, at 10:56 AM, Antoni Przygienda <[e-mail]<mailto:[e-mail]>> wrote:
Read the draft on the plane trying to figure out what’s that about. Observations


a)      First, the draft seems to indicate that it’s draft-rosen (6037) and I assume it’s talking about the P-G PIM which is generated by the PE and then first P is acting as BER. And it seems to concern mostly SSM. Just verifying …

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


b)      I’m suspicious of the 256bits argument somehow. Is the idea that running a single-SI BIER is somehow massively simpler than multiple-SI-s? The packet WILL split @ replication points & replication is necessary in any case (unless we have ingress rep for which BIER is not needed) so I don’t see how single-SI makes much of a difference.

There are two goals:
- Stay with a single SI to avoid packet duplication in a core due to a scale.
- Intro BIER in the core without a need to touch access domains - evolutionary intro of BIER.



c)       We do not need to burn a protocol bit for PIM albeit yes, it would be tad more efficient. PIM must be carried in either v4 or v6 frame which is its normal encoding and already fully supported by BIER encaps. Additionally, if PIM is stripped of v4/v6 encaps considerations would have to be made to all the PIM RPF & correct source/destination addresses checks in the spec AFAIR. Yes, the BER needs to look into v4/v6 packets to  see PIM being tunneled but if we try to accommodate every IP protocol with a bit, we’ll run out fast. Accomodating a protocol makes most sense when we talk heavy-volume dataplane such as maybe VxLAN if we can save headers for processing speed but PIM is a low volume control protocol and the check is trivial since it’s a well known next-protocol offset position.

Let's discuss in Prague.


d)      I think the moniker BRT is ill chosen. BIER does not do RPF and using “RPF” here to describe tracking of G-membership of P-BFRs is overloading the term in a confusing way IMO. Basically in overlay we should have a G to BFM mapping (and if necessary S to BFR-id derived from BIER packets) and nothing else. There is no “RPF” lookup per packet or anything like this which the moniker suggests (yes, one would say we do a “RPF” per “PIM join” but that somehow implies that such “RPF” can “fail and drop” which it cannot).

e)      The whole “RPF SPF lookup” in 3.1 for (S,G) joins will not work in general case AFAIS. Observe that BIER may NOT be IGP signaled (but e.g. controller based) or run subdomain over a MT sub-setting links or construct a different tree than SPF so this “PIM tunneled (S,G) overlay” seems to violate the separation of layers completely as proposed assuming that it can draw conclusions from IGP state (i.e. it considers the tunnel path somehow “backwards-computable” by the overlay making it not a tunnel but an encapsulation only).
This is bot trying to be a general solution that will work with every BIER deployment. It intends to solve brown-deployment use caee in some pretty typical architecture deployed today.

If the whole (S,G) join architecture hinges on assumption that a “future” BIER packet’s source can be “figured out by computing SPF” then it is very restricted and those assumptions have to be spelled out very clearly. In general case an (S,G) join would have to be sent to all BERs that participate in the P-G IMO make is de-facto ASM is my impression.


Maybe I somehow miss the whole point completely given that the text is jumping between tons of technologies and seems to not state assumptions taken every time clearly …


Let's go over confusing parts tony so we can clarify and avoid those in the text.

Andrew

--- tony

_______________________________________________
BIER mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bier