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

[IJsbrand Wijnands <[e-mail]>]

Robert,

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

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,
> 
> > [Tony said]  ???  Last I checked SPRING was defining a 
> > unicast dataplane.
> 
> 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) <[e-mail]> wrote:
> 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: "[e-mail]" <[e-mail]>
> Date: Friday, September 26, 2014 at 5:01 PM
> To: IJsbrand Wijnands <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "Eric Rosen (erosen)" <[e-mail]>, Antoni Przygienda <[e-mail]>
> Subject: Re: [Bier] One specific transition churn ...
> 
> 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.
> 
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
> 
>