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

From: Antoni Przygienda <[email-masked]>
Date: Tue, 18 Jul 2017 08:56:49 +0000

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 …

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.

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.

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

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 …

--- tony

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Tue, 18 Jul 2017 09:18:04 +0000

Inline

Andrew

Sent from my iPhone

On Jul 18, 2017, at 10:56 AM, Antoni Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

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

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.

Let's discuss in Prague.

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.

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

Andrew
--- tony

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

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 18 Jul 2017 11:23:39 +0200

ok, starts to make more sense if you spell all those assumptions very
explicitly in the boilerplate. And give more examples ideally ...

I'm on the floor the whole week, ping me 1:1 and we'll talk ...

--- tony

On Tue, Jul 18, 2017 at 11:18 AM, Dolganow, Andrew (Nokia - SG/Singapore) <
[email-masked]> wrote:

> Inline
>
> Andrew
>
> Sent from my iPhone
>
> On Jul 18, 2017, at 10:56 AM, Antoni Przygienda <[email-masked]> wrote:
>
> 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 …
>
>
> 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:
> 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 …
>
>
>
>
> [email-masked]
> [email-masked]

-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 18 Jul 2017 16:20:12 -0400

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.

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 18 Jul 2017 20:34:58 +0000

Hi Eric

I just need to clarify a point and maybe it is easier to have face to face discussion.

We are not trying to create a PIM adjacency via BIER. It is more like mLDP tunneling concept.

We are trying to send the join and prune msg via BIER domain toward source and BIER RPF keeps track of these joins.

That said you are correct it is application unaware weather in GRT or VRF.

Again if you are floor love to have a face to face chat before the session.

Regards

Hooman

From: BIER [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Tuesday, July 18, 2017 4:20 PM
To: Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>; Antoni Przygienda <[email-masked]>
Cc: [email-masked]
Subject: Re: [Bier] Comments on draft-hfa-bier-pim-tunneling

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.

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.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 18 Jul 2017 17:21:25 -0400

> We are not trying to create a PIM adjacency via BIER. It is more like 

By "mLDP tunneling concept" are you referring to mLDP "in-band 
signaling" (RFC6826)?

If you are sending PIM Join/Prune messages from one router to another, 
then the routers are PIM adjacencies, and I don't see how you can avoid 
treating them as such.
This does raise a lot of issues -- what if the Join has Join attributes 
in it, how can you tell what Join attributes are supported unless you 
have Hellos, etc.  Also, by carrying PIM Join/Prune messages, you retain 
the issues that come from periodic retransmission of the Join/Prune 
messages.

mLDP in-band signaling doesn't carry PIM Join/Prune messages, it just 
carries the (S,G) information.  It does have some ASM issues because 
there is no "prune this source off the shared tree" operation.  Or to 
put it another way: mLDP in-band signaling does not tunnel PIM over 
mLDP, it splices several PIM trees together with a P2MP LSP.   If you 
want your scheme to function like mLDP in-band signaling, you need to 
say a lot more about how the BIER-PIM Join/Prune messages are 
constructed and how they are processed.

That would be a less general solution than using BIER  to emulate a 
link.  It would also need to be compared to other forms of overlay 
signaling such as MVPN-based GTM.

> love to have a face to face chat before the session. 

Unfortunately I am not in Prague.

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Wed, 19 Jul 2017 07:29:27 +0000

Inline

Andrew

Sent from my iPhone

On Jul 18, 2017, at 10:20 PM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> wrote:

Correct. We will look at ASM as well for completeness.

Correct.

The slides Hooman will present will explain how and why we gravitate towards this solution.

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 19 Jul 2017 16:07:27 +0200

On Tue, Jul 18, 2017 at 10:20 PM, Eric C Rosen <[email-masked]> wrote:

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

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

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

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

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

---

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

With the two stated goals:

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:[email-masked]] On Behalf Of Dolganow, Andrew (Nokia - SG/Singapore)
Sent: Tuesday, July 18, 2017 11:18 AM
To: Antoni Przygienda <[email-masked]>
Cc: [email-masked]
Subject: Re: [Bier] Comments on draft-hfa-bier-pim-tunneling

Inline

Andrew

Sent from my iPhone

There are two goals:

Let's discuss in Prague.

Andrew

--- tony

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 21 Jul 2017 09:46:26 +0000

Inline

Regards

Hooman

From: BIER [mailto:[email-masked]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Thursday, July 20, 2017 7:21 AM
To: Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>; Antoni Przygienda <[email-masked]>
Cc: [email-masked]
Subject: Re: [Bier] Comments on draft-hfa-bier-pim-tunneling

HB> ok agreed…

HB> agreed with PBR, will use the term I-PBR and E-PBR.

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

HB> will work on this thank you!

   of signaling.

HB> this is Provider PIM, but as previously agreed. This draft would work independent of MVPN or GRT.

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

HB> Auto discovery of MVPN

Jeffrey

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

Inline

Andrew

Sent from my iPhone

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

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

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

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

Andrew

--- tony