On 09/06/2017 03:59, Michael Richardson wrote:
> 
> Brian E Carpenter <[email protected]> wrote:
>     > Well yes, but for discovery & flooding you actually need to emulate
>     > multicast. GRASP assumes that the ACP VRF will do that. If not, GRASP
>     > would have to access the adjacency table and send N copies. I could
>     > code that, but I don't think I should need to.
> 
> GRASP is doing application layer multicast.  That's why we have those
> session-IDs, and the checking and the caching, etc.

Wel, I think the session IDs are equally relevant for unicast, especially
if we do develop a UDP-unicast model later. But the model described
in GRASP relies explicitly on link-local IP multicast, that's why we
have a LL multicast address assigned. We do not rely on multicast routing,
because that makes us dependent on the data plane. But we do rely
on discovery and flood being sent to all neighbours. How else can they
work?

So this is why I've been asking the ACP authors to be precise about the
service they will offer to GRASP, over many months. They tell me it
will be a VRF instance providing a reasonably small number of (virtual)
interfaces to GRASP. GRASP will send LL multicasts to each of those
interfaces, and the VRF instance has to do the right thing, i.e. replicate
those multicasts as needed. But that's layer 3, it just has LL scope.

Nothing new here that I can see.

    Brian

> 
> It's news to me that the ACP will emulate layer-2 multicast!
> 
> I expected GRASP to send a copy on each interface (you do that now!), and the
> ACP will present each link in the VRF as an interface.
> 
> If you want multicast support in the ACP, would you like:
>    1) PIM? (dense or sparse)
>    2) MPL?
>    3) something totally bleeding edge (but very cool) like BIER?
> 
> 
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
> 

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to