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

[Robert Raszuk <[e-mail]>]

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