Brian,
I support the publication of this document, but I have one (non-blocking) comment...
Thanks!
I do not see any forwarding plane discussions in this document and I wonder if there was discussion about impacts on multicast forwarding. With the removal of the VPN-related checks, is there a possibility of loops in the forwarding of multicast data based on the GTM information? What about implications for RPF checks?
I don't think there are any issues here. Is there something specific that concerns you?
As in MVPN, each egress node still has to select an ingress node for a given flow, and has to discard traffic that is not from that ingress node. This requires that the egress be able to infer the identity of the ingress from the data packet's encapsulation. But the relevant mechanisms are not impacted by the fact that there is no VPN-specific context.
Similarly, the procedures for setting up the multicast tunnels are not impacted by the lack of VPN-specific context; if the global table unicast routing is loop-free, the resulting multicast trees should be loop-free as well.
Eric _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
