Subject: [Bier] One specific transition churn ...

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Sep 2014 19:16:39 +0200

Aren't we worried about impact of joins to the controller followed by churn
of rewrite changes on ingress router ?

Worst case is single receivers behind egress router joining and leaving ..
or a lot of them.

In traditional multicast joining the tree is sort of local .. in BIER
entire control plane is impacted.

At min perhaps the draft should introduce stability timers which would
effectively continue to forward given set of groups to the egress routers
even if receivers behind them leaves.

I realize that with BGP multicast procedures we have already stepped out of
multicast native behavior, however BGP has number of build in mechanisms to
well deal with churn. Is the assumption here that the associated signalling
of BIER will be BGP based ?

Rgs,
r.

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Fri, 26 Sep 2014 17:29:48 +0000

Hi Robert,

Good question.

As you say, when adding PIM (S,G)/(*,G) join information into BGP we already crossed a line there.

There is already a draft out there to deal with this: http://tools.ietf.org/id/draft-morin-multicast-damping-01.txt

For MVPN, BGP seems like an obvious choice, all the procedures we need are already defined. For other use cases we might as well go with some sort of SDN controller approach. The attractive proposition of BIER is that the controller only needs to connect to the Ingress and Egress routers. It does not need to connect to the core routers because there is no tree to build :-) This is the beauty of the stateless approach!

Thx,

Ice.

Sent from my iPad

On 26 Sep 2014, at 19:16, "Robert Raszuk" <[email-masked]<mailto:[email-masked]>> wrote:

Aren't we worried about impact of joins to the controller followed by churn of rewrite changes on ingress router ?

Worst case is single receivers behind egress router joining and leaving .. or a lot of them.

In traditional multicast joining the tree is sort of local .. in BIER entire control plane is impacted.

At min perhaps the draft should introduce stability timers which would effectively continue to forward given set of groups to the egress routers even if receivers behind them leaves.

I realize that with BGP multicast procedures we have already stepped out of multicast native behavior, however BGP has number of build in mechanisms to well deal with churn. Is the assumption here that the associated signalling of BIER will be BGP based ?

Rgs,
r.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Sep 2014 19:35:36 +0200

Hey Ice,

> It does not need to connect to the core routers because
> there is no tree to build :-) This is the beauty of the stateless
> approach!

Well of course .. this is principal element of the BIER architecture.

An interesting question for me is when this "stateless" nature crosses the
cost vs benefit equation ?

Clearly if you have few groups and hand full of receivers (for example of
high bandwith HD TV channels) I hardly see much of BIER advantage. But if
you have 1000s of groups and 100s of egress routers by all means simplicity
is quite obvious.

But it would be highly interesting to find such middle sweet spot in number
of groups/number of receivers expected in the network.

Cheers,
R.

On Fri, Sep 26, 2014 at 7:29 PM, IJsbrand Wijnands (iwijnand) <[email-masked]
> wrote:

>  There is already a draft out there to deal with this:
> http://tools.ietf.org/id/draft-morin-multicast-damping-01.txt
>
>  For MVPN, BGP seems like an obvious choice, all the procedures we need
> are already defined. For other use cases we might as well go with some sort
> of SDN controller approach. The attractive proposition of BIER is that the
> controller only needs to connect to the Ingress and Egress routers. It does
> not need to connect to the core routers because there is no tree to build
> :-) This is the beauty of the stateless approach!
>
>  Thx,
>
>  Ice.
>
> Sent from my iPad
>
> On 26 Sep 2014, at 19:16, "Robert Raszuk" <[email-masked]> wrote:
>
>
>  Aren't we worried about impact of joins to the controller followed by
> churn of rewrite changes on ingress router ?
>
>  I realize that with BGP multicast procedures we have already stepped out
> of multicast native behavior, however BGP has number of build in mechanisms
> to well deal with churn. Is the assumption here that the associated
> signalling of BIER will be BGP based ?
>
>  Rgs,
> r.
>
>

---

From: Antoni Przygienda <[email-masked]>
Date: Fri, 26 Sep 2014 17:39:36 +0000

Not sure this is a discussion about BIER multicast overlay or BIER layer (look @ arch). For the multicast overlay the discussion makes sense but it's kind of orthogonal to BIER itself.

A BIER layer is in a sense a 'distributed multicast fabric' only, it couldn't care whether it even runs IP multicast and people join/leave, it's basically a way to stitch together BFIRs to BFERs and if it carries something else than IP multicast on it, no damage done (and possibly lots good ;-). In a sense it's like PMSI being used for other things in IP beside IP multicast right now.    So don't think about it as "oooh, a G joins, this needs to join as a BFER".  Think about a fabric you can put into IP that all of a sudden gives you all-inclusive, selective, bi- or unidirectional P-channels in a single shot. If overlay wants to flip BFERs on/off based on a G joining, well, their choice, if it just keeps all the PEs together, it's another use & the pruning of the BFER receivers for the PEs that have the G happens in overlay sending over BIER 'fabric'.

The 'no tree necessary' is fibbing a little ;-)  It basically piggy-backs on existing SPF today (while the architecture allows possibly other trees in the future to improve the tradeoff of replication vs. avg. path-length to deliver a packet).

--- tony

From: BIER [mailto:[email-masked]] On Behalf Of IJsbrand Wijnands (iwijnand)
Sent: Friday, September 26, 2014 10:30 AM
To: Robert Raszuk
Cc: Eric Rosen (erosen); [email-masked]; IJsbrand Wijnands (iwijnand)
Subject: Re: [Bier] One specific transition churn ...

Hi Robert,

Good question.

Thx,

Ice.

Sent from my iPad

Rgs,
r.

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Fri, 26 Sep 2014 17:58:06 +0000

Robert,

You assume that Bier cannot localize this, I personally think there is a way to make sure that as receivers come and go, we do not need to flood this in IGP for BIER – especially in MVPN case.

Andrew

On 2014-09-26, 1:16 PM, "Robert Raszuk" wrote:

Rgs,
r.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Sep 2014 20:49:38 +0200

As far as I understand it no one is targeting use of IGP for signalling of
join requests in BIER overlay. But I am very novice to BIER so may be
missing something :)

My question was specific to whatever signalling is used other then IGP as
well as amount of state transition on ingress specifically number of data
plane rewrite headers changes per sec/min in the worst case scenario.

best,
r.

On Fri, Sep 26, 2014 at 7:58 PM, Dolganow, Andrew (Andrew) <
[email-masked]> wrote:

>  Robert,
>
>  You assume that Bier cannot localize this, I personally think there is a
> way to make sure that as receivers come and go, we do not need to flood
> this in IGP for BIER – especially in MVPN case.
>
>  Andrew
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Sep 2014 20:55:26 +0200

Tony,

Many thx for the explanation. When I first read the doc I understood it
precisely as you state it below.

But then BIER to me is a special case of SPRING and therefor I find it odd
to have a BOF and define yet one more separate data plane ...

Also I think without control plane example (of say IP multicast) BIER alone
will be hard to progress forward. Each new proposal as far as I see these
days in IETF needs some for of its rationale for existence example :)

So you are correct - my point was not about BIER as DMF, but as specific
example of running IP multicast on top of this. Is this a wrong list to ask
such questions if so I apologies, but Ice recommended I share previously
sent offline question to him to this list.

Cheers,
R.

On Fri, Sep 26, 2014 at 7:39 PM, Antoni Przygienda <
[email-masked]> wrote:

>  Not sure this is a discussion about BIER multicast overlay or BIER layer
> (look @ arch). For the multicast overlay the discussion makes sense but
> it’s kind of orthogonal to BIER itself.
>
>
>
> A BIER layer is in a sense a ‘distributed multicast fabric’ only, it
> couldn’t care whether it even runs IP multicast and people join/leave, it’s
> basically a way to stitch together BFIRs to BFERs and if it carries
> something else than IP multicast on it, no damage done (and possibly lots
> good ;-). In a sense it’s like PMSI being used for other things in IP
> beside IP multicast right now.    So don’t think about it as “oooh, a G
> joins, this needs to join as a BFER”.  Think about a fabric you can put
> into IP that all of a sudden gives you all-inclusive, selective, bi- or
> unidirectional P-channels in a single shot. If overlay wants to flip BFERs
> on/off based on a G joining, well, their choice, if it just keeps all the
> PEs together, it’s another use & the pruning of the BFER receivers for the
> PEs that have the G happens in overlay sending over BIER ‘fabric’.
>
>
>
> The ‘no tree necessary’ is fibbing a little ;-)  It basically piggy-backs
> on existing SPF today (while the architecture allows possibly other trees
> in the future to improve the tradeoff of replication vs. avg. path-length
> to deliver a packet).
>
>
>
> --- tony
>
>
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *IJsbrand
> Wijnands (iwijnand)
> *Sent:* Friday, September 26, 2014 10:30 AM
> *To:* Robert Raszuk
> *Cc:* Eric Rosen (erosen); [email-masked]; IJsbrand Wijnands (iwijnand)
> *Subject:* Re: [Bier] One specific transition churn ...
>
>
>
> Hi Robert,
>
>
>
> Good question.
>
>
>
> For MVPN, BGP seems like an obvious choice, all the procedures we need are
> already defined. For other use cases we might as well go with some sort of
> SDN controller approach. The attractive proposition of BIER is that the

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 26 Sep 2014 20:21:29 +0000

Hi Robert,

Please see inline,

My question was specific to whatever signalling is used other then IGP as well as amount of state transition on ingress specifically number of data plane rewrite headers changes per sec/min in the worst case scenario.

Zero impact on ingress node if membership (for whatever number of S,Gs) on any egress node changes from 1000 to 1 or 1 to 500 or whatever number, every time interval (second, say).

This is because the bit (in bier header) is set per egress node. Another beauty of bier. :)

Of course, there is an impact on the ingress node if the membership changes from zero to non-zero number or non-zero to zero on any egress node. The frequency of such a change is expected to be on the lower side (depending on the use case*).

But let's say, If there are 1000 egress nodes and each of them experiences membership for any of 100 groups going to/from zero every 60 seconds (arguably a rare scenario in use-cases like stock ticker or IPTV) , then there would be 1000 rewrite events every 60 seconds on the Ingres node.

As far as I understand it no one is targeting use of IGP for signalling of join requests in BIER overlay.

You are right. None so far.

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services
CITT CTO Office

On Sep 26, 2014, at 2:49 PM, "Robert Raszuk" <[email-masked]<mailto:[email-masked]>> wrote:

As far as I understand it no one is targeting use of IGP for signalling of join requests in BIER overlay. But I am very novice to BIER so may be missing something :)

My question was specific to whatever signalling is used other then IGP as well as amount of state transition on ingress specifically number of data plane rewrite headers changes per sec/min in the worst case scenario.

best,
r.

On Fri, Sep 26, 2014 at 7:58 PM, Dolganow, Andrew (Andrew) <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Andrew

Rgs,
r.

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

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Fri, 26 Sep 2014 20:25:25 +0000

Hi Robert,

But then BIER to me is a special case of SPRING and therefor I find it odd to have a BOF and define yet one more separate data plane ...

BIER is totally unrelated to SPRING, completely different data-plane!

So you are correct - my point was not about BIER as DMF, but as specific example of running IP multicast on top of this. Is this a wrong list to ask such questions if so I apologies, but Ice recommended I share previously sent offline question to him to this list.

This is a good question to ask on this list because BIER requires explicit tracking of the receivers, so, good question :-)

Thx

Ice.

Cheers,
R.

On Fri, Sep 26, 2014 at 7:39 PM, Antoni Przygienda <[email-masked]<mailto:[email-masked]>> wrote:
Not sure this is a discussion about BIER multicast overlay or BIER layer (look @ arch). For the multicast overlay the discussion makes sense but it’s kind of orthogonal to BIER itself.

A BIER layer is in a sense a ‘distributed multicast fabric’ only, it couldn’t care whether it even runs IP multicast and people join/leave, it’s basically a way to stitch together BFIRs to BFERs and if it carries something else than IP multicast on it, no damage done (and possibly lots good ;-). In a sense it’s like PMSI being used for other things in IP beside IP multicast right now.    So don’t think about it as “oooh, a G joins, this needs to join as a BFER”.  Think about a fabric you can put into IP that all of a sudden gives you all-inclusive, selective, bi- or unidirectional P-channels in a single shot. If overlay wants to flip BFERs on/off based on a G joining, well, their choice, if it just keeps all the PEs together, it’s another use & the pruning of the BFER receivers for the PEs that have the G happens in overlay sending over BIER ‘fabric’.

The ‘no tree necessary’ is fibbing a little ;-)  It basically piggy-backs on existing SPF today (while the architecture allows possibly other trees in the future to improve the tradeoff of replication vs. avg. path-length to deliver a packet).

--- tony

From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of IJsbrand Wijnands (iwijnand)
Sent: Friday, September 26, 2014 10:30 AM
To: Robert Raszuk
Cc: Eric Rosen (erosen); [email-masked]<mailto:[email-masked]>; IJsbrand Wijnands (iwijnand)
Subject: Re: [Bier] One specific transition churn ...

Hi Robert,

Good question.

Thx,

Ice.

Sent from my iPad

Rgs,
r.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Sep 2014 23:01:01 +0200

> BIER is totally unrelated to SPRING, completely different data-plane!

​Perhaps it is today, but the question is - does it need to be a yet one
more completely new data-plane ?

Take SPRING IPv6 ... why extension header could not list all egress nodes
as well as ​

​list of transit BFRs where replication to said egress nodes is to take
place ?

Or going step further .. send list of BFRs (like SNs) and program the
required replication out of band (from controller) avoiding carrying
bitstring or network protocols to build a tree to accomplish easy way of
optimal replication ? Is keeping multicast groups such an overkill for even
an average network device these days ?

Last but not least how is said bitstring to be honored, accepted and used
between domains ? What NNI is to be agreed for BIER to make it usable
between AS under different administrations ?

Thx,
r.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 26 Sep 2014 23:31:47 +0200

> Worst case is single receivers behind egress router joining and leaving .. or a lot of them. 

What is the expectation of accuracy here?

If a receiver leaves, the BFER will stop forwarding to that.
How bad is it that the BFER still receives a copy of the packet from the BFIR?

(And conversely, what are the join latencies expected here?)

Grüße, Carsten

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Sep 2014 23:37:43 +0200

Hi Carsten,

> copy of the packet from the BFIR?

IMHO not bad at all. Hence suggested timer to continue to fwd before
withdraw of the join request by the timer.

Such timer btw can be adaptive to the BFER history.

Cheers,
R.

---

From: Antoni Przygienda <[email-masked]>
Date: Fri, 26 Sep 2014 23:15:56 +0000

But then BIER to me is a special case of SPRING

[Tony said]  ???  Last I checked SPRING was defining a unicast dataplane.

Also I think without control plane example (of say IP multicast) BIER alone will be hard to progress forward. Each new proposal as far as I see these days in IETF needs some for of its rationale for existence example :)

[Tony said]  I could figure out from Eric’s draft how mVPN is supposed to work over it as example. I’m working on another service draft. thus shall be ‘nuff examples in short time.

[Tony said] no, asked in multicast overlay it’s a perfect question, it’s just kind of orthogonal to whether you run BIER layer IMO. Anything that changes core-state based on single joins will ‘shake it’.  The question is what is perceived as ‘bad shake’. Computations ? Re-advertising information ?

--- tony

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Sat, 27 Sep 2014 13:27:00 +0000

Hi Robert,

Take SPRING IPv6 ... why extension header could not list all egress nodes as well as ​

​list of transit BFRs where replication to said egress nodes is to take place ?

Or going step further .. send list of BFRs (like SNs) and program the required replication out of band (from controller) avoiding carrying bitstring or network protocols to build a tree to accomplish easy way of optimal replication ? Is keeping multicast groups such an overkill for even an average network device these days ?

<Nagendra> BiER doesn’t need any IGP calculation for every multicast group joined by BFER. Infact, it simply leverage the unicast tale and populate the BIFT table. So instead of programming different transit nodes for optimal replication for every new group, I think it is simple to have the tree built once (which doesn’t need additional SPF other than unicast calculation) and still achieve optimal forwarding.

Last but not least how is said bitstring to be honored, accepted and used between domains ? What NNI is to be agreed for BIER to make it usable between AS under different administrations ?

<Nagendra> I think this is slightly covered in below draft,

http://tools.ietf.org/html/draft-rosen-l3vpn-mvpn-bier-00

Thanks,
Nagendra

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 26, 2014 at 5:01 PM
To: IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Eric Rosen (erosen)" <[email-masked]<mailto:[email-masked]>>, Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] One specific transition churn ...

​Perhaps it is today, but the question is - does it need to be a yet one more completely new data-plane ?

Take SPRING IPv6 ... why extension header could not list all egress nodes as well as ​

​list of transit BFRs where replication to said egress nodes is to take place ?

Or going step further .. send list of BFRs (like SNs) and program the required replication out of band (from controller) avoiding carrying bitstring or network protocols to build a tree to accomplish easy way of optimal replication ? Is keeping multicast groups such an overkill for even an average network device these days ?

Last but not least how is said bitstring to be honored, accepted and used between domains ? What NNI is to be agreed for BIER to make it usable between AS under different administrations ?

Thx,
r.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Sep 2014 16:28:41 +0200

Hi Nagendra,

> <Nagendra> BiER doesn’t need any IGP calculation
> for every multicast group joined by BFER.

I am not talking about IGP. Where is this assumption coming from I do not
know.

All agree that BFER receives a join for new group that has to somehow
travel to BFIR as well as BFIR must adjust its data plane. That is the
churn I was referring to.

Hi Tony,

> [Tony said]  ???  Last I checked SPRING was defining a

Where does it say so in the SPRING charter ???

http://datatracker.ietf.org/wg/spring/charter/

Cheers,
r.

On Sat, Sep 27, 2014 at 3:27 PM, Nagendra Kumar Nainar (naikumar) <
[email-masked]> wrote:

>   <Nagendra> BiER doesn’t need any IGP calculation for every multicast
> group joined by BFER. Infact, it simply leverage the unicast tale and
> populate the BIFT table. So instead of programming different transit nodes
> for optimal replication for every new group, I think it is simple to have
> the tree built once (which doesn’t need additional SPF other than unicast
> calculation) and still achieve optimal forwarding.
>
>   Last but not least how is said bitstring to be honored, accepted and
> used between domains ? What NNI is to be agreed for BIER to make it usable
>   From: "[email-masked]" <[email-masked]>
> To: IJsbrand Wijnands <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "Eric Rosen (erosen)" <
> [email-masked]>, Antoni Przygienda <[email-masked]>
>   Last but not least how is said bitstring to be honored, accepted and
> used between domains ? What NNI is to be agreed for BIER to make it usable
> [email-masked]

---

From: Antoni Przygienda <[email-masked]>
Date: Sat, 27 Sep 2014 16:03:47 +0000

[Tony said] I fail to see a loose or not loose ‘source route’ in BIER encapsulation, only destinations.  Ultimately, we can argue that IETF needs a single protocol and encapsulation and transport and OAM working group called ‘bits-on-the-wire’ only.  In widest sense, any kind of ontology can be put on top of the world if argued for it strenuously enough and everything made the same ‘thing’.

--- tony

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 27 Sep 2014 09:22:29 -0700

> Take SPRING IPv6 ... why extension header could not list all egress nodes as well as ​     ​list of transit BFRs where replication to said egress nodes is to take place ? 

Even though this is a horrible idea since the length of the packet would be so large even past the point where people complain about GRE, VXLAN, and LISP headers adding overhead. And they typically are only 16 bytes. Also, you would have to make even more copies of the packet since the SI would have to be smaller when encoding full addresses. 

But the fact people will have to manage yet another address space (ie BFR-IDs) makes you wonder if the OpEx will be any less than the points made in the problem statement ID. 

Dino

---

From: Antoni Przygienda <[email-masked]>
Date: Sat, 27 Sep 2014 17:07:30 +0000

Dino

[Tony said]  Hey ;-)   yepp, $$$ OpEx/CapEx spending less or same is the _real_ question as to whether BIER should be brewed ;-)   Less replication = less money spent on CapeX but mVPN using other PMSIs can do that.  New addressing = more money spent on OpEx (BIER controllers ;-) but that can be handled by autoconfiguration as well ;-) If interested in that, ping me privately, I have some amount of work put into fairly readable format for that problem done already.

Overall, maybe the question is even Opex/Capex running all the MCast machinery necessary today (protocol OpEx) for MCast under new services such as mVPN vs. just running BIER PMSI  to do the same. My distinct feeling was that BIER will be a win (if all the hooks are in place to scale it) & that what attracted me to get dragged into couple discussions over high-quality beer ;-)

--- tony

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 27 Sep 2014 11:43:58 -0700

> But the fact people will have to manage yet another address space (ie BFR-IDs) makes you wonder if the OpEx will be any less than the points made in the problem statement ID. 

Not to mention a new adjacency protocol and mapping between the routes the IGP/unicast-routing computes to BFR-IDs. There is a dependency there just like there was a dependency of RPF on unicast routing in traditional IP multicast.

The clever part of the idea, is to encode a list of things (BFERs) in a small encoding space. IMO, better than a general source-route. But that comes a cost because you need BFR-IDs and SIs.

I'm also concerned the way this is being marketed. The term "overlay" is being used in many places. Well the original definition of overlay means you don't have to change the center or core of the network. What is being proposed is exactly that, change the core so native replication can occur but keep the edges (multicast sourcs and receivers and potentially PIM routers at existing domains) untouched.

> Dino
>  
> [Tony said]  Hey ;-)   yepp, $$$ OpEx/CapEx spending less or same is the _real_ question as to whether BIER

Well with enough thrust anything can fly. You want to brew if you are really sure people want to taste it. ;-)

> should be brewed ;-)   Less replication = less money spent on CapeX but mVPN using other PMSIs can do that.

Well traditional IP multicast and MPLS multicast has less replication. And mVPNs, as designed, and deployed are limited to specific provider and have scaling issue because the functionality in PEs limits the number of customers you can really add.

>  New addressing = more money spent on OpEx (BIER controllers ;-) but that can be handled by autoconfiguration as well ;-) If interested in that, ping me privately, I have some amount of work put into fairly readable format for that problem done already.

Yes, this argument is used a lot. Build complexity in the system so it has a certain level of robustness. Then you hide the complexity with network management. If you haven't noticed, we have been trying to recently fix network management the last couple of years (read: SDN). But it doesn't matter, when things go wrong, you MUST know how the protocol works and you must understand the elements involved (network entities) and the elements of operation. And things always go wrong.  ;-)

> Overall, maybe the question is even Opex/Capex running all the MCast machinery necessary today (protocol OpEx) for MCast under new services such as mVPN vs. just running BIER PMSI  to do the same.…

What is being proposed can be done with typical overlay multicast and I know the authors are aware of the multicast work done in the LISP WG. When you do a true multicast overlay, then you can put the edges ANYWHERE in the network because you don't have to change the core AT ALL.

The LISP overlay multicast proposals have traditional signaling approaches only to interoperate with IGMP and PIM domains, but there is also a signal-free proposal that avoids building distribution trees. And you do make use of unicast forwarding (and not BFR forwarding which is a completely new data-plane) so OpEx is lowered dramstically because you are using legacy/traditional unicast forwarding methods.

Dino

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Sep 2014 21:03:24 +0200

> What is being proposed can be done with typical overlay multicast and I
> know the authors are aware of the multicast work done in the LISP WG. When
> you do a true multicast overlay, then you can put the edges ANYWHERE in the
> network because you don't have to change the core AT ALL.
>

​And that IMO would be much better option all together rather then keep
upgrading routers and their OSes all the time :)

Btw while not a BIER question how does LISP m-cast compares with
http://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01

​Or for that matter with peercasting ? ​

​- - - ​

​As to BIER how is it suppose to work in say DC environment where I run BGP
and no IGP at all ? Just like described here:

http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-07

Thx,
​r.​

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 27 Sep 2014 12:58:02 -0700

> 
>  does LISP m-cast compares with http://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01
> 

I don't know. I have not read either of them. But as usual there are only so many ways to solve similar problems so there is likely some overlap in the solution space. 

Dino

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sun, 28 Sep 2014 09:19:04 +0200

Robert,

> I am not talking about IGP. Where is this assumption coming from I do not know. 

You're missing the point Nagendra is making.

SPRING is Source routing, the path is pre-determined on the ingress and forwarded based on the hops included in the packet (not on IGP).

BIER forwarding is based on IGP, the Bits in the BIER header are looked up in the IGP on a per hop basis and forwarded accordingly.

If you’re next reply is going to suggest we need source routed paths for multicast, work through a couple of examples before pressing the send button :-)

Thx,

Ice.

> 
> All agree that BFER receives a join for new group that has to somehow travel to BFIR as well as BFIR must adjust its data plane. That is the churn I was referring to. 
> 
> Hi Tony,
> 
> On Sat, Sep 27, 2014 at 3:27 PM, Nagendra Kumar Nainar (naikumar) <[email-masked]> wrote:
> Hi Robert,
> 
> Cc: "[email-masked]" <[email-masked]>, "Eric Rosen (erosen)" <[email-masked]>, Antoni Przygienda <[email-masked]>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sun, 28 Sep 2014 09:33:51 +0200

Hi Dino,

> But the fact people will have to manage yet another address space (ie BFR-IDs) makes you wonder if the OpEx will be any less than the points made in the problem statement ID. 

The customers we have talked to do not see this as a big deal. We can come up with automated mechanism to assign the BFR-id, but then you have yet an other protocol to learn. It does not get any simpler than applying this via configuration. Also, configurations are often managed centrally and push to the routers.

Thx,

Ice.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 28 Sep 2014 11:57:29 +0200

H​ello Ice,​

> BIER forwarding is based on IGP, the Bits in the BIER header are looked up
> in the IGP on a per hop basis and forwarded accordingly.
>

​For the last 10+ years we both have heard number of real customer requests
no to follow IGP for multicast streams.

P2MP RSVP-TE is one example ..

We have also seen number of valid reasons for disjoined distribution of the
*same* streams.

BIER architecture mentions the option to use multi-topology extensions. But
it is not clear to me how the encapsulation carries which MT index given
packet should use at any BFR.
​
Perhaps the label you are advertising in IGP for the BFR is already a
context label ?

But is MT really sufficient ?

It is not clear to me how I can practically build equivalent of 100 P2MP
RSVP-TE trees for say HD TV with MT.

For the "disjoned" requirement while you can build different topologies and
put different links in it to create N planes the bandwith efficiency of
such solution and the opex to maintain it would be rather close to
nightmare.

> If you’re next reply is going to suggest we need source routed paths for
> multicast, work through a couple of examples before pressing the send
> button :-)
>

​You missed my point. I was talking about the case where you have a hard
requirement to use RSVP-TE like path which segment routing can do. Then at
the end of last segment use bitstring (possibly with SIs) for efficient
replication.

Your current solution replication relies heavily on IGP to make the
forwarding and replication as efficient as possible. But as Dino already
said this is not an OVERLAY at all. Sure it is much better then using
native protocols to build a m-cast tree in the WAN, but it is still very
heavy network centric solution.

And even so not all core network routers need to be BFRs the way I
understand current proposal all edge routers must participate in the IGP
extensions to get any multicast packet sent to it by BIER - isn't it ?

Of course one option is to have OSPF ABR or ISIS L1L2 to act as BIER proxy
and maybe even we will see a draft poping up soon on it :) But again it
will be network centric solution ...

Cheers,
R.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sun, 28 Sep 2014 13:18:55 +0200

Robert,

You keep re-homing the discussion to a different topic again and again.

The point we are making is that BIER does not belong in SPRING.

Thx,

Ice.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 28 Sep 2014 14:03:57 +0200

​Ice,​

> You keep re-homing the discussion to a different topic again and again.

​I asked few questions to better understand the proposal. Most of them have
not been answered so far :)​

> The point we are making is that BIER does not belong in SPRING.

SPRING charter says:

"The SPRING working group will define procedures that
will allow a node to steer a packet along an explicit
route using information attached to the packet and
without the need for per-path state information to be
held at transit nodes. Full explicit control (through loose or strict path
specification) can be achieved in a network comprising only SPRING nodes,
however SPRING must inter-operate through loose routing in existing
networks and may find it advantageous to use loose routing for for other
network applications.​"

​Why I see similarities:​

* ​BIER adds information (bitstring/SI) to the packets on ingress which
determine how the packet is to be forwarded via the network nodes. ​

* While BIER does not add explicit path one can interpret bitstring as
special case of Loose Path Specification where you indicate just the egress
points or SI-subnets.

Anyway if you want to have a new group for it - make it happen. What to me
is more important however is how the BIER will be useful in practice.

Cheers,
R.

---

From: Greg Shepherd <[email-masked]>
Date: Sun, 28 Sep 2014 05:14:14 -0700

Thanks Robert. We've currently asked for a non-WG BoF in HI. Based on the
discussion here on the list, and that in the BoF, the community will make a
decision as to IF this work should be adopted by the IETF, and if so, where
the work should take place. It has been my experience that every WG in the
IETF not specifically working on mcast issues treats any mcast requirements
as the bastard stepchild and those mcast reqs never fully get addressed.

In some cases they've even punted the mcast reqs over to MBONED which is in
OPS and should not be working on protocols. BIER is intended to
specifically address a set of mcast issues. Having a focused community to
addresses them is most likely the fastest path to success.

Greg

On Sun, Sep 28, 2014 at 5:03 AM, Robert Raszuk <[email-masked]> wrote:

> ​I asked few questions to better understand the proposal. Most of them
> have not been answered so far :)​
>
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sun, 28 Sep 2014 14:24:19 +0200

Robert,

> * ​BIER adds information (bitstring/SI) to the packets on ingress which determine how the packet is to be forwarded via the network nodes. ​

Incorrect, the Bit in the string determines who receives the packet, not how it is forwarded.

> * While BIER does not add explicit path one can interpret bitstring as special case of Loose Path Specification where you indicate just the egress points or SI-subnets.

You mean like a destination IP address in the IP packet is also a loose path? I disagree.

Thx,

Ice.

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 28 Sep 2014 13:13:17 +0000

> You mean like a destination IP address in the IP packet is also a loose path? I

[Tony said]  I agree with Ice, argument here has been led ad absurdum. We are here to explain, help and discuss and appreciate interest on this list but in this case I suggest the discussion 'which WG does it belong into' to be taken off this the list currently towards A-Ds & the proponents of where it belongs may have a little patience until a BOF happens (if) and enough interest and consensus shows (if) and a WG is suggested to form (if).  

--- tony

---

From: Gregory CAUCHIE <[email-masked]>
Date: Mon, 29 Sep 2014 11:28:00 +0200

Hi,

I strongly support the motivation exposed below by Greg Sheperd.

The first lines of SPRING charter states :
    "The ability for a node to specify a forwarding path, other
    than the normal shortest path, that a particular packet
    will traverse, benefits a number of network functions, "

This make me disagree with Robert's view (at least from what I 
understood) as SPRING talks about a construction of a forwarding path 
while BIER talks about creating a list of egress routers and a way of 
coping with the risk of receiving multiple copy of the same packet... 
but in the same time I think I am as curious as Robert about the 
ressemblance/difference/combination of SPRING and BIER. THerefore I 
think that at some point it would be interesting to discuss potential 
interaction/application of BIER and SPRING.

--
Greg Cauchie

Le 28/09/2014 14:14, Greg Shepherd a écrit :
> Thanks Robert. We've currently asked for a non-WG BoF in HI. Based on 
> the discussion here on the list, and that in the BoF, the community 
> will make a decision as to IF this work should be adopted by the IETF, 
> and if so, where the work should take place. It has been my experience 
> that every WG in the IETF not specifically working on mcast issues 
> treats any mcast requirements as the bastard stepchild and those mcast 
> reqs never fully get addressed.
>
> In some cases they've even punted the mcast reqs over to MBONED which 
> is in OPS and should not be working on protocols. BIER is intended to 
> specifically address a set of mcast issues. Having a focused community 
> to addresses them is most likely the fastest path to success.
>
> Greg
>
> On Sun, Sep 28, 2014 at 5:03 AM, Robert Raszuk <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Ice,
>
>     I asked few questions to better understand the proposal. Most of
>     them have not been answered so far :)
>
>     held at transit nodes. Full explicit control (through loose or
>     strict path specification) can be achieved in a network comprising
>     only SPRING nodes, however SPRING must inter-operate through loose
>     routing in existing networks and may find it advantageous to use
>     loose routing for for other network applications."
>
>     Why I see similarities:
>
>     * BIER adds information (bitstring/SI) to the packets on ingress
>     which determine how the packet is to be forwarded via the network
>     nodes.
>
>     * While BIER does not add explicit path one can interpret
>     bitstring as special case of Loose Path Specification where you
>     indicate just the egress points or SI-subnets.
>
>     Anyway if you want to have a new group for it - make it happen.
>     What to me is more important however is how the BIER will be
>     useful in practice.
>
>     Cheers,
>     R.
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 29 Sep 2014 05:42:33 -0700

On Sat, Sep 27, 2014 at 9:22 AM, Dino Farinacci <[email-masked]> wrote:

> Even though this is a horrible idea since the length of the packet would
> be so large even past the point where people complain about GRE, VXLAN, and
> LISP headers adding overhead.
>

Can you define "so large"? A BIER domain is well defined set, and not
global.

> And they typically are only 16 bytes. Also, you would have to make even
> more copies of the packet since the SI would have to be smaller when
> encoding full addresses.
>

BIER is explicite replication, as the name implies. The objective is to no
more copies than next-hop neighbors.

> But the fact people will have to manage yet another address space (ie
> BFR-IDs) makes you wonder if the OpEx will be any less than the points made
> in the problem statement ID.
>

This has yet to come up in any operator discussions. In every case the
perceived benefits out way the challenges.

Greg